Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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 <deller@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).