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

[Daniel P . Berrangé]

On Fri, Apr 05, 2019 at 11:02:52AM +0200, Helge Deller wrote:
> On 05.04.19 10:26, Daniel P. Berrangé wrote:
> > 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.
> 
> libvirt was just one example, and yes, it's possible to work around in
> multiple ways.
> 
> As another example, even if I only want to build "qemu-img", I still need
> to manually give the --enable-tcg-interpreter configure option.

That is something I would consider a valid bug to fix. We should permit
people to do  "./configure --disable-system --disable-user --enable-tools".
Requiring --enable-tcg-interpreter in that scenario is clearly wrong,
as we're not even building it.

> >> 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.
> 
> Yes, fair point.
> Sadly such special treatment by projects makes life for me
> as an architecture maintainer much harder :-(

FWIW I like to see code portability that is as broad as is practical.
At the same time though, essentially every open source project is
massively overloaded with work they want to accomplish vs number of
contributors available.

There has to be a tradeoff in where effort is spent and usually that
tradeoff ends up priortizing areas that are going to benefit the
largest number of users. In recent times QEMU has been trying to
formalize what it considers supported vs unsupported so that we have
a better plan for where we spend our limited contributor resources.
The intent is that this will help us improve overall project quality.
That has meant dropping support for many older distros, and marking
some OSes, distros & architectures as unsupported with a view to fully
dropping ability to build on them in future.

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