Hi Helge, On 4/5/19 9:56 AM, Helge Deller wrote: > On 05.04.19 03:34, Peter Maydell wrote: >> On Fri, 5 Apr 2019 at 01:59, Helge Deller <del...@gmx.de> wrote: >>> If a non-release architecture is found, and it's known that there is no >>> native TCG support for that CPU, automatically fall back to the TCI >>> implementation instead of requesting the user to run configure again >>> with the --enable-tcg-interpreter option. >>> >>> This change simplifies building qemu in automatic build environments >>> (like in my case the debian buildds) because one does not need to >>> special case on the architectures. >> >> I don't think we should do this. TCI is unmaintained, has several >> known flaws, > > Just out of interest: Is there a list with those flaws somewhere?
The last big discussion is in this thread: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06528.html >> does not provide the level of performance that >> people expect from QEMU, and we've talked about removing it >> altogether. In particular, distros should not automatically ship >> a TCI QEMU -- it's something that a user can use if they >> explicitly opt into but which I don't think we want to surprise >> anybody with. > > I won't argue against your points. They are all valid. > >> If we care about a host architecture we should support it >> with a proper TCG backend. If we don't care that much we >> shouldn't support it. > > Looking just at some of the debian "ports" (non-release) architectures: > alpha, hppa, ia64, m68k, powerpc, sh4, sparc64 > Most likely nobody will ever care enough to write a TCG backend for those, > and it doesn't even make sense because they are so much slower than > the currently supported TCG backend architectures. So why should one want > to emulate a fast x86 machine on slow m68k for example? >From experience: when a m68k compiler is only provided as a x86 binary and you want to recompile m68k code on an embedded m68k with no network access. Another example appeared last year on the list, when using a binary compiled for a more recent ISA on an outdated ISA. > The only reason when it *can* make sense is, when you need "basic" > emulation or availability of binaries for cross-dependecies in distros, > e.g. to build other packages or to be able to install other packages. > As one example, many packages depend on libvirt (frontend tools, monitoring > stuff, ...) and libvirt again depends on some qemu binaries. > So, having qemu buildable (even if the result is slow) makes life easier. > > I know, my point above now turns into a "distro packaging" issue. > That's why I'm questioning, why should distros (or even direct end-users) > be forced to distinguish between architectures? > Shouldn't running "./configure" find out what's available and then > auto-configure itself to the *best* what's possible? > > And, my patch still prints the warning that that's an unsupported > architecture, at the end of configure there is still the big warning > about "*this architecture may go away*", and if someone complains about > performance on such an architecture you can still happily invite him to > write the TCG backend. > > Anyway, if you think Philippe's suggestion of "why not add a "hppa" case > selecting > TCI in the switch?" is the better solution, then I'm happy to send such a > patch > instead. I suggested that as a "less worth" approach, but I'm 100% with Peter on this. I understand your use and still think this should be handled by Debian for his "ports" (non-release) architectures, as an explicit selected option on the list you mentioned (alpha, hppa, ia64, m68k, powerpc, sh4, sparc64).
