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

Peter Krempa pkrempa at redhat.com
Wed Jun 3 08:40:21 UTC 2020

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.

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

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

More information about the libvir-list mailing list