[libvirt] [PATCH 0/5] tests: Refresh/add capabilities for QEMU 4.0.0

[Daniel P. Berrangé]

On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
> On Tue, 2019-04-30 at 15:02 +0200, Pavel Hrdina wrote:
> > On Tue, Apr 30, 2019 at 02:44:06PM +0200, Andrea Bolognani wrote:
> > > On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
> > > > Peter sent the same patch for x86_64 as well, there is one difference,
> > > > you also have all the Xen things enabled which would be nice to not
> > > > have it there since we don't care about it.
> > > > 
> > > > I acked Peter's patch so can you please re-post again with
> > > > --disable-xen appended to the configure of QEMU?
> > > 
> > > We might not care in RHEL, but we certainly *do* care upstream.
> > 
> > Not correct, sure we care about the Xen hypervisor and drivers but we
> > do not care about the Xen stuff in QEMU driver where we use replies.
> > 
> > > More specifically, I built both QEMU and libvirt on Fedora 29 after
> > > running 'dnf builddep' for the respective packages, so there should
> > > be nothing enabled that would not be enabled in the Fedora packages:
> > > in fact, I compared the replies and they're identical.
> > 
> > Yes, in fedora the Xen part is enabled because Xen uses QEMU to
> > emulate some aspects of the VM and Xen is supported there so the
> > dependencies to enable Xen support in QEMU are there by default.
> 
> Alright, the difference was partially lost on me. I now agree that
> we don't need to have the Xen bits enabled in QEMU, and consequently
> don't have any problem with Peter's patch being merged instead of
> mine.
> 
> > > Additionally, if you check out the existing replies you'll see that
> > > we had Xen support compiled into QEMU when we generated those for
> > > versions 2.8, 2.9 and 2.10. And no, not all of those were provided
> > > by me... You might actually be surprised when looking at the git
> > > history for those files ;)
> > 
> > This is never a good argument :) if something was done in some way in
> > the past it doesn't mean that it's correct or preferred in present.
> 
> I completely agree, but in this case there's nothing problematic
> with having Xen support built into QEMU when probing capabilities.
> 
> Realistically speaking, a significant number of libvirt developers
> are on Fedora, so replies generated from a QEMU build that includes
> Xen support is going to sneak in again eventually. And it will not
> cause any harm.
> 
> 
> Anyway, the rest of the replies were generated from QEMU binaries
> built on RHEL, and on non-x86 architectures too, so we don't have to
> worry about those accidentally containing Xen support :)

IMHO we should not generate standard replies from the QEMU binaries
from RHEL, unless we are specifically looking to cover the RHEL fork
of QEMU. RHEL cannot be consistently assumed to match upstream QEMU
behaviour due to RHEL's fairly aggressive patch backporting. The
Fedora builds are essentially vanilla upstream code, so a better bet
for generic capabilities.


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