Now that it's officially out, we can refresh existing capabilities
created from git snapshots and introduce them for the architectures
where they were missing altogether.

This series covers all architectures except for s390x, to which I
don't have convenient access: Pino promised me he'd take care of that
one in a few days.

As usual for this kind of series, most patches have been snipped with
extreme prejudice in order to make them small enough that they
wouldn't end up in the moderation queue: the unabridged version can
be found at

  https://github.com/andreabolognani/libvirt

in the 'qemucaps-4.0.0' branch.

It'd be great if we could sneak these in during the freeze so that I
won't have to possibly regenerate them again after the post-release
merge flood ;)

Andrea Bolognani (5):
  tests: Refresh capabilities for QEMU 4.0.0 on x86_64
  tests: Refresh capabilities for QEMU 4.0.0 on riscv32
  tests: Refresh capabilities for QEMU 4.0.0 on riscv64
  tests: Add capabilities for QEMU 4.0.0 on aarch64
  tests: Add capabilities for QEMU 4.0.0 on ppc64

 .../qemu_4.0.0.x86_64.xml                     |     3 +-
 ...v32.replies => caps_4.0.0.aarch64.replies} |  6997 ++--
 .../caps_4.0.0.aarch64.xml                    |   310 +
 ...scv32.replies => caps_4.0.0.ppc64.replies} | 29886 ++++++++++------
 .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml |  1077 +
 .../caps_4.0.0.riscv32.replies                |    10 +-
 .../caps_4.0.0.riscv32.xml                    |     4 +-
 .../caps_4.0.0.riscv64.replies                |    10 +-
 .../caps_4.0.0.riscv64.xml                    |     4 +-
 .../caps_4.0.0.x86_64.replies                 |  3331 +-
 .../caps_4.0.0.x86_64.xml                     |    38 +-
 ...arch64-os-firmware-efi.aarch64-latest.args |     2 +-
 .../aarch64-virt-graphics.aarch64-latest.args |     2 +-
 .../aarch64-virt-headless.aarch64-latest.args |     2 +-
 14 files changed, 25862 insertions(+), 15814 deletions(-)
 copy tests/qemucapabilitiesdata/{caps_4.0.0.riscv32.replies => caps_4.0.0.aarch64.replies} (86%)
 create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
 copy tests/qemucapabilitiesdata/{caps_4.0.0.riscv32.replies => caps_4.0.0.ppc64.replies} (71%)
 create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml

-- 
2.20.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
> Now that it's officially out, we can refresh existing capabilities
> created from git snapshots and introduce them for the architectures
> where they were missing altogether.
> 
> This series covers all architectures except for s390x, to which I
> don't have convenient access: Pino promised me he'd take care of that
> one in a few days.
> 
> As usual for this kind of series, most patches have been snipped with
> extreme prejudice in order to make them small enough that they
> wouldn't end up in the moderation queue: the unabridged version can
> be found at
> 
>   https://github.com/andreabolognani/libvirt
> 
> in the 'qemucaps-4.0.0' branch.
> 
> It'd be great if we could sneak these in during the freeze so that I
> won't have to possibly regenerate them again after the post-release
> merge flood ;)

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?

Pavel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
> On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
> > Now that it's officially out, we can refresh existing capabilities
> > created from git snapshots and introduce them for the architectures
> > where they were missing altogether.
> > 
> > This series covers all architectures except for s390x, to which I
> > don't have convenient access: Pino promised me he'd take care of that
> > one in a few days.
> > 
> > As usual for this kind of series, most patches have been snipped with
> > extreme prejudice in order to make them small enough that they
> > wouldn't end up in the moderation queue: the unabridged version can
> > be found at
> > 
> >   https://github.com/andreabolognani/libvirt
> > 
> > in the 'qemucaps-4.0.0' branch.
> > 
> > It'd be great if we could sneak these in during the freeze so that I
> > won't have to possibly regenerate them again after the post-release
> > merge flood ;)
> 
> 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.

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.

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 ;)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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:
> > On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
> > > Now that it's officially out, we can refresh existing capabilities
> > > created from git snapshots and introduce them for the architectures
> > > where they were missing altogether.
> > > 
> > > This series covers all architectures except for s390x, to which I
> > > don't have convenient access: Pino promised me he'd take care of that
> > > one in a few days.
> > > 
> > > As usual for this kind of series, most patches have been snipped with
> > > extreme prejudice in order to make them small enough that they
> > > wouldn't end up in the moderation queue: the unabridged version can
> > > be found at
> > > 
> > >   https://github.com/andreabolognani/libvirt
> > > 
> > > in the 'qemucaps-4.0.0' branch.
> > > 
> > > It'd be great if we could sneak these in during the freeze so that I
> > > won't have to possibly regenerate them again after the post-release
> > > merge flood ;)
> > 
> > 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.

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

Pavel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2019-04-30 at 14:27 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
> > 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.

I built upstream QEMU *on* RHEL, then generated replies from those
binaries. Whatever patching is done to QEMU in RHEL, it does not at
any point enter the picture.

I could conceivably provision the same machines with Fedora and build
QEMU + libvirt there, but that would be quite a bit of extra work on
top of something that's not fun nor quick to do in the first place,
so I'd rather keep using RHEL as the build OS. I'm also unconvinced
the result would be substantially different.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 30, 2019 at 03:41:18PM +0200, Andrea Bolognani wrote:
> On Tue, 2019-04-30 at 14:27 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
> > > 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.
> 
> I built upstream QEMU *on* RHEL, then generated replies from those
> binaries. Whatever patching is done to QEMU in RHEL, it does not at
> any point enter the picture.
> 
> I could conceivably provision the same machines with Fedora and build
> QEMU + libvirt there, but that would be quite a bit of extra work on
> top of something that's not fun nor quick to do in the first place,
> so I'd rather keep using RHEL as the build OS. I'm also unconvinced
> the result would be substantially different.

Ah, that's reasonably safe right now, as QMP is largely static. So
even if features are disabled at build time, most stuff still appears
in QMP.  QMP is getting more dynamic though, so that it respects
build time choices better. Thus in future we should aim to ahve
a consistent (maximum) set of features enabled in QEMU builds.


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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list