[PATCH] tests: qemucapabilities: Update qemu caps dump for the qemu-7.0.0 release on x86_64
Igor Mammedov
imammedo at redhat.com
Wed Apr 20 12:44:51 UTC 2022
On Wed, 20 Apr 2022 14:13:00 +0200
Peter Krempa <pkrempa at redhat.com> wrote:
> On Wed, Apr 20, 2022 at 14:00:52 +0200, Igor Mammedov wrote:
> > On Wed, 20 Apr 2022 12:21:03 +0100
> > Daniel P. Berrangé <berrange at redhat.com> wrote:
> >
> > > On Wed, Apr 20, 2022 at 01:15:43PM +0200, Igor Mammedov wrote:
> > > > On Wed, 20 Apr 2022 13:02:12 +0200
> > > > Peter Krempa <pkrempa at redhat.com> wrote:
> > > >
> > > > > Few minor changes in qemu since the last update:
> > > > > - PIIX4_PM gained 'x-not-migrate-acpi-index' property
> > > >
> > > > do you do this for just for every new property?
> > > > (nothing outside of QEMU needs to know about x-not-migrate-acpi-index,
> > > > unless one is interested in whether it works or not)
> > >
> > > This is simply a record of what QEMU reports when you query properties
> > > for the devices libvirt cares about.
> >
> > I was just curious why libvirt does it.
> >
> > > If nothing outside is supposed to
> > > know about x-not-migrate-acpi-index then QEMU shouldn't tell us about
> > > it when asked for properties :-)
> >
> > Does livirt uses/exposes x- prefixed property anywhere?
> > (i.e. can QEMU hide them?)
>
> I don't think it's needed to hide them. In fact we have strong rules
> against using them.
>
> With one notable exception:
>
> -object memory-backend-file,x-use-canonical-path-for-ramblock-id=
>
> But this was discussed extensively on the qemu list and qemu pledges
> that this specific property is considered stable.
ok lets leave it as is.
More information about the libvir-list
mailing list