Re: [Qemu-devel] [RFC PATCH 0/8] removal of tci (tcg interpreter)

[Stefan Weil]

Am 29.06.2017 um 03:02 schrieb Philippe Mathieu-Daudé:
> There have been some comments on the ML about the usefulness of tci.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04551.html
> 
>   Peter Maydell> I'd prefer we just got rid of it.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04296.html
> 
>   Richard Henderson> Is it time to remove it? I'm pretty sure the only hosts
>                      for which it will work have proper backends...
> 
> Richard quotes are way clearer than me trying to paraphrase what he told me:
> - it doesn't use libffi, and as such the way it makes calls to helpers 
> doesn't work for many hosts.
> - we already cover almost everthing that debian does. if debian or gentoo 
> doesn't support it, one can confidently say there's little interest.
> - if someone *does* want to run qemu on something else, it isn't difficult to 
> port tcg.
> 
> I figured out MAINTAINERS was unsync, so added patches 1-4, they are not 
> really
> tci-related.
> 
> Patches 5,6 are trivial fixes to let the codebase quite sane if there is 
> future
> need to revert/reimport tci.
> 
> Patches 7,8 are the removal, marked RFC... let's debate!
> 
> Regards,
> 
> Phil.


Hi,

as Peter already has written, there are different perspectives on QEMU.

My conclusion is that depending on those perspectives people come to
different results whether certain code parts are useful or not.

When I started using (and contributing) to QEMU in 2006, I wanted to
analyse code running on an embedded MIPS system. With real hardware
that was impossible, but with QEMU I could watch and debug that code
(as soon as the MIPS emulation was sufficiently good, so that was
my initial motivation).

Later I was responsible for automated software tests. Those tests
included software written for embedded PCs. The only missing components
for an emulation with QEMU were the network cards, so I wrote the
eepro100 (part of official QEMU) and dp8381x (only in my fork)
network hardware emulations.

Later I wanted to build and run QEMU on platforms which were not
implemented. So that was the motivation to write TCI. I also used
TCI to analyse TCG commands with Valgrind. It is for example very
easy to count the frequency of the different TCG opcodes executed
in an emulation run. TCI could also be used to monitor register
usage with minimal code changes. And I still think that it is
the easiest way to build QEMU on a completely new platform
(that should work out of the box) and to make emulation work
there (that might require some efforts).

In my current role I'm interested in the emulation of old computer
systems. Therefore my fork still includes some hardware emulations
which were removed in the official QEMU, and especially emulation
of all generations of the Intel PC platform is important for me.

I am aware that neither of those applications is in the primary
focus of most QEMU developers who want to have a stable, well
performing platform for server virtualisation. My server
qemu.weilnetz.de also uses that technology, so I want that, too.

Nevertheless QEMU is the only software which I know which not
only addresses the needs for server / PC virtualisation, but
also is useful for researchers and scientists, archivists,
learners and teachers or experimenters.

Up to now, I had the impression that QEMU is sufficiently modular
so that the different perspectives and expectations could be
supported without harming each other too much. The only drawback
was additional code (which would not be needed when focussing on
a single perspective) causing additional compilation time
and more (formal, mostly automated) file changes for code clean
ups and API‌ changes.

Cheers
Stefan