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

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.