qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] machine: add missing doc for memory-backend option


From: Igor Mammedov
Subject: Re: [PATCH v3] machine: add missing doc for memory-backend option
Date: Wed, 27 Jan 2021 20:19:52 +0100

On Wed, 27 Jan 2021 18:41:46 +0000
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Wed, Jan 27, 2021 at 07:30:24PM +0100, Michal Privoznik wrote:
> > On 1/27/21 6:56 PM, Daniel P. Berrangé wrote:  
> > > On Wed, Jan 27, 2021 at 04:35:22PM +0100, Igor Mammedov wrote:  
> > > > On Wed, 27 Jan 2021 15:24:26 +0100
> > > > Michal Privoznik <mprivozn@redhat.com> wrote:
> > > >   
> > > > > On 1/27/21 11:54 AM, Daniel P. Berrangé wrote:  
> > > > > > On Wed, Jan 27, 2021 at 10:45:11AM +0000, Daniel P. Berrangé wrote: 
> > > > > >  
> > > > > > > On Thu, Jan 21, 2021 at 11:15:04AM -0500, Igor Mammedov wrote:  
> > > > > 
> > > > >   
> > > > > > > 
> > > > > > > How does a mgmt app know which machine types need to use this
> > > > > > > option ? The machine type names are opaque strings, and apps
> > > > > > > must not attempt to parse or interpret the version number
> > > > > > > inside the machine type name, as they can be changed by
> > > > > > > distros.  IOW, saying to use it for machine types 4.0 and
> > > > > > > older isn't a valid usage strategy IMHO.  
> > > > it's possible (but no necessary) to use knob with new machine types
> > > > (defaults for these match suggested property value).  
> > > 
> > > IIUC, this means that setting the property has no impact on
> > > migration ABI for new machine types > 4.0....
> > >   
> > > > Limiting knob usage to 4.0 and older would allow us to drop
> > > > without extra efforts once 4.0 is deprecated/removed.  
> > > 
> > > ...so, even if we set the property unconditionally for *all*
> > > machine types, then we can still remove it in future, becuase
> > > its removal won't affect ABI of the 5.x, 6.x machine types.  
> > 
> > Alright, so after all you agree with proposed patch? I'm a bit confused.  
> 
> +        b) for machine types 4.0 and older, user shall
> +        use ``x-use-canonical-path-for-ramblock-id=off`` backend option
> +        if migration to/from old QEMU (<5.0) is expected.
> 
> instead of refering to machine type versions, I think it
> could say something more like
> 
> 
>       b) if the ``x-use-canonical-path-for-ramblock-id`` property
>          exists, it should be set to ``off``, 
>          if migration to/from old QEMU (<5.0) is expected.

Documentation describes exact limitations/req.
libvirt can't distinguish types so it can ignore it and apply to all machine 
types.
Others may use it as described if they are able to distinguish
machine types.
So I'd like to keep it the way it's written instead of putting
blanket over all machine types.

> Assuming it genuinely does not have any ABI impact on new machine
> types.
x-use-canonical-path-for-ramblock-id is 'off' by default, so
if one turns off it explicitly it won't change anything for
new machine types.

> 
> Regards,
> Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]