[PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x

[Shalini Chellathurai Saroja]

On 12/17/20 12:19 PM, Andrea Bolognani wrote:
> 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 at redhat.com>
>
> and pushed. Thanks for helping!

Hello Andrea,

Thank you for the review:-) Sure, you are welcome:-)

>
> 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.
The replies are actually generated from the QEMU 5.2.0 binary built 
exclusively
from upstream. This is also true for the other s390 replies generated for
the earlier versions of QEMU. I can modify the package name from
qemu-5.2.0-20201215.0.ba93e22c.fc32 to qemu-5.2.0, to make it more
obvious that it is an upstream version and not a distro package. Would 
it be ok?

>
> Thanks again for your help getting updated capabilities in libvirt :)
You are welcome:-)
>
-- 
Kind regards
Shalini Chellathurai Saroja
Linux on Z and Virtualization Development
Vorsitzende des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294