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
