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

[Daniel P . Berrangé]

On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
> Hi Peter,
> 
> On 05.04.19 03:34, Peter Maydell wrote:
> > On Fri, 5 Apr 2019 at 01:59, Helge Deller <address@hidden> 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?
> 
> > 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?
> 
> 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.

If it is just a matter of satisfying dependencies, it is easy to build
a minimal libvirt that is essentially just the client libraries and not
the QEMU driver that would in turn allow other packages to build. Alternatively
it should be possible to build the downstream apps with their libvirt dep
disabled avoiding pulling in the whole virtualization chain as a build
pre-req.

> 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?

"best" depends on the POV. You want configure to enable support on
hppa by default since you have an interest in that architecture, which
is fine. The QEMU maintainers, however, have a POV that considers
raising an error by default to be the "best" solution for architectures
that are considered unsupported, requiring explicit arg to optin to use
unsupported features.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|