On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: > tests/domaincapsdata/qemu_5.2.0.s390x.xml | 231 + > .../caps_5.2.0.s390x.replies | 25458 ++++++++++++++++ > .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 3300 ++ > ...default-video-type-s390x.s390x-latest.args | 9 +- > .../disk-error-policy-s390x.s390x-latest.args | 16 +- > .../fs9p-ccw.s390x-latest.args | 8 +- > ...tdev-subsys-mdev-vfio-ap.s390x-latest.args | 4 +- > ...ubsys-mdev-vfio-ccw-boot.s390x-latest.args | 4 +- > ...othreads-virtio-scsi-ccw.s390x-latest.args | 6 +- > ...t-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 4 +- > ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 9 +- > ...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 4 +- > ...t-cpu-tcg-ccw-virtio-4.2.s390x-latest.args | 4 +- > .../s390x-ccw-graphics.s390x-latest.args | 8 +- > .../s390x-ccw-headless.s390x-latest.args | 8 +- > .../vhost-vsock-ccw-auto.s390x-latest.args | 8 +- > .../vhost-vsock-ccw.s390x-latest.args | 8 +- > 17 files changed, 29054 insertions(+), 35 deletions(-) > create mode 100644 tests/domaincapsdata/qemu_5.2.0.s390x.xml > create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.replies > create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml The diff looks sane enough, so Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> and pushed. Thanks for helping! However... > +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml > @@ -0,0 +1,3300 @@ > +<qemuCaps> > + <emulator>/usr/bin/qemu-system-s390x</emulator> > + <version>5002000</version> > + <kvmVersion>0</kvmVersion> > + <microcodeVersion>39100243</microcodeVersion> > + <package>qemu-5.2.0-20201215.0.ba93e22c.fc32</package> ... the version string seems to indicate you're grabbing the replies from a packaged version rather than a build made from pristine upstream sources: this is consistent with what was done for earlier QEMU capabilities on s390x, but not with how we usually do things for other architectures - see the other caps_5.2.0.*.replies files. I don't think this is a blocker, because a Fedora-based package will be quite close to upstream anyway, but it would be great if you could generate the replies file again against a QEMU binary that's been built exclusively from upstream sources. You can then submit the update as a follow-up patch - I expect such patch to be fairly small. Thanks again for your help getting updated capabilities in libvirt :) -- Andrea Bolognani / Red Hat / Virtualization
