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

Shalini Chellathurai Saroja shalini at linux.ibm.com
Tue Jan 12 13:21:47 UTC 2021

On 1/12/21 11:09 AM, Andrea Bolognani wrote:
> On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote:
>> On 1/4/21 9:44 AM, Andrea Bolognani wrote:
>>> On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote:
>>>> On 12/17/20 12:19 PM, Andrea Bolognani wrote:
>>>>> On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote:
>>>>>> +++ 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.
>>> So how are you actually building the binary? Because if you just
>>> clone the upstream repository and run the usual ./configure && make
>>> inside it, the version number will not look like that... The presence
>>> of .fc32 specifically seems to indicate a .spec file is involved in
>>> some capacity.
>> Hello Andrea,
>> Happy New Year:-)
>> We are using an automated build system which creates rpm packages from
>> upstream QEMU 5.2.0.
>> Yes, a .spec file is involved.
> I see.
> As long as you're using unadulterated upstream sources I don't think
> we have a problem here, and you shouldn't spend time changing your
> process.
I agree, thank you:-)
> Thanks again!
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

More information about the libvir-list mailing list