Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
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(a)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