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

[Peter Maydell]

On 29 June 2017 at 19:09, Stefan Weil <address@hidden> wrote:
> 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.

Yes, the whole of TCG demonstrates that we're not purely
trying to be a virtual-machine-usecase-only codebase,
so certainly there is scope for having multiple parts
and uses in QEMU.

I think the part of TCI that makes it stand out as awkward
here is that it is an option that you have to pick at
configure time, and enabling it disables the standard
TCG backend. If it was a runtime option to use the
interpreter rather than the codegen (in the same way that
you can runtime select between KVM and TCG), I think that
would help a lot:
 * reduces the number of build configs we need to test
 * means it's accessible to the bulk of users who use their
   distro's build of QEMU rather than rolling their own
 * less of a beartrap for users who enable the config
   option and then wonder why QEMU is running so slowly
 * opens the possibility of using the interpreter as part
   of mainstream TCG (eg in the cases of "execute one
   insn and throw it away, which might be faster
   interpreted in theory)

TCI is also awkward because it means we don't really know
what the set of platforms we run on is. (For instance I'd
like to fix our configure script which currently uses 'uname'
as a fallback for identifying target CPU and OS, which
is totally wrong for cross-compile. It would be easier to
be sure such a refactor was correct if we knew which
hosts we could possibly run on...)

That to me all adds up to a position where while I don't
care enough to take active steps to remove TCI from QEMU,
I wouldn't be unhappy to see it go if other people strongly
support removal, and if nobody's interested in trying to
fix its problems.

thanks
-- PMM