[PATCH v2 1/1] tests: qemucapabilities: update ppc64 qemu caps for 7.0.0 release

[Andrea Bolognani]

On Mon, May 09, 2022 at 07:27:57AM -0300, Daniel Henrique Barboza wrote:
> On 5/9/22 07:00, Andrea Bolognani wrote:
> > Would you be okay with something like
> >
> >    There are no major changes since 7.0.0-rc2, but a few additional
> >    features are enabled in this build.
> >
> > ? If so, I can amend the commit message and push the patch
>
> Yes please, go ahead. Thanks!

Done.

> I've
> installed the following packages in a Power9 running Fedora35:
>
> dnf install libusb-devel  libcap-ng-devel libssh-devel libpmem-devel \
> libiscsi-devel libnfs-devel libseccomp-devel libseccomp-static \
> liburing-devel libbpf-devel librbd-devel \
> libcurl-devel libaio-devel \
> egl-utils egl-wayland-devel \
> virglrenderer-devel \
> gtk+-devel spice-gtk3-devel \
> fuse3-devel gtkglext-devel \
> lzo-devel brlapi-devel snappy-devel

FYI you don't have to play a guessing game here, and you can just
look at the contents of

  tests/docker/dockerfiles/fedora.docker

to figure out what packages you need to install.

> Aside from that, in the end it's hard to distinguish between "this feature isn't
> present in ppc64" versus "the host that generated the capabilities didn't have the
> support installed" because it's the same thing from the qemucaps standpoint.

I was thinking more about the fact that the diff for
caps_7.0.0.ppc64.xml is massive, but really it should look like

  @@ -133,6 +133,7 @@
     <flag name='machine.pseries.cap-nested-hv'/>
     <flag name='egl-headless.rendernode'/>
     <flag name='memory-backend-file.align'/>
  +  <flag name='memory-backend-file.pmem'/>
     <flag name='nvdimm.unarmed'/>
     <flag name='scsi-disk.device_id'/>
     <flag name='virtio-pci-non-transitional'/>
  @@ -193,6 +194,8 @@
     <flag name='compat-deprecated'/>
     <flag name='acpi-index'/>
     <flag name='input-linux'/>
  +  <flag name='virtio-gpu-gl-pci'/>
  +  <flag name='virtio-vga-gl'/>
     <flag name='confidential-guest-support'/>
     <flag name='query-display-options'/>
     <flag name='set-action'/>
  @@ -210,10 +213,10 @@
     <flag name='virtio-iommu-pci'/>
     <flag name='virtio-iommu.boot-bypass'/>
     <flag name='virtio-net.rss'/>
  -  <version>6002092</version>
  +  <version>7000000</version>
     <kvmVersion>0</kvmVersion>
     <microcodeVersion>42900243</microcodeVersion>
  -  <package>v7.0.0-rc2</package>
  +  <package>v7.0.0</package>
     <arch>ppc64</arch>
     <cpu type='kvm' name='default' typename='604-powerpc64-cpu'/>
     <cpu type='kvm' name='ppc' typename='604-powerpc64-cpu'/>

Those are the only meaningful changes to the file: everything else is
just CPU models and machine types being shuffled around.

The same is true for the replies file: there are some actual
differences, but the patch is made unnecessarily big by the fact that
commands like query-machines and qom-list-types are returning lists
that have very similar contents but are ordered differently.

There's an argument to be made for storing QEMU's output verbatim,
but I don't see why we wouldn't guarantee that at least the data we
produce is not affected by this? Specifically, we could list CPU
models and machine types in alphabetical order.

-- 
Andrea Bolognani / Red Hat / Virtualization