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
