On 29 June 2017 at 19:09, Stefan Weil <s...@weilnetz.de> 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
