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@redhat.com> 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