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

[Daniel Henrique Barboza]

On 5/9/22 10:30, Andrea Bolognani wrote:
> 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.

Noted.

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

I agree that trying to check the differences between different capabilities
file isn't trivial. Alphabetical order is a good start.


Thanks,


Daniel


>