[PATCH] qemucapabilitiestest: Bump qemu-5.1 capabilities for x86_64

Michal Privoznik mprivozn at redhat.com
Wed Jun 3 09:11:08 UTC 2020


On 6/3/20 10:40 AM, Peter Krempa wrote:
> On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote:
>> On 6/3/20 9:31 AM, Peter Krempa wrote:
>>> QEMU added the machine types for the 5.1 release so let's update them.
>>>
>>> Other notable changes are 'cpu-throttle-tailslow' migration property,
>>> 'zlib' compression for qcow2 images and absrtact socket support.
>>>
>>> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>>> ---
>>> As usual, I'll be refreshing this until the release so that we always
>>> have fresh capabilities to prevent any surprises with deprecation and
>>> big updates.
>>>
>>>    .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml  |   2 +-
>>>    .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml  |   2 +-
>>>    tests/domaincapsdata/qemu_5.1.0.x86_64.xml    |   2 +-
>>>    .../caps_5.1.0.x86_64.replies                 | 357 +++++++++++-------
>>>    .../caps_5.1.0.x86_64.xml                     |  14 +-
>>>    5 files changed, 237 insertions(+), 140 deletions(-)
>>
>> Reviewed-by: Michal Privoznik <mprivozn at redhat.com>
>>
>> Maybe we can have another rule that would allow you to push these without
>> review? I can argue both ways, so I'm just putting it out there.
> 
> Yeah. I thought about that too.
> 
> Specifically one thing I'd like to avoid is carelessness in case of the
> update. Specifically if there is some form of removal (flag being
> removed and such) we need to be careful and consider the implications.

Well, for that we would need to compare with older capabilities XML and 
I don't think we are doing that. Removal between the same capabilities 
XML of an unreleased QEMU are uncommon. But I hear what you're saying 
and that's my concern too.

> 
> In this very specific case there's nothing of note and I'd be okay with
> just pushing it, but the rules if we wanted to codify it somehow would
> require to be more nuanced and I don't think I can express all the
> caveats.
> 
> That's why I didn't really argue for adding a special rule for this.
> 
> Also one reason I'm doing periodic upgrades of this is so that others
> don't have to do it. The problem here is that the output is very much
> dependent on the machine where you run it and I don't want others to
> have to update the files when adding a new capability as the difference
> becomes unreviewable and may even regress depending on how qemu is
> built.
> 

This is a long known issue and perhaps it would be worth documenting 
somewhere? I think these are QEMU binaries taken from Fedora, is that 
so? Maybe we can document configure arguments for QEMU so that it is 
reproducible.

Michal




More information about the libvir-list mailing list