[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

[Igor Mammedov]

On Tue, 12 Jan 2021 20:59:11 +0100
Peter Krempa <pkrempa at redhat.com> wrote:

> On Tue, Jan 12, 2021 at 20:24:44 +0100, Igor Mammedov wrote:
> > On Tue, 12 Jan 2021 18:41:38 +0000
> > Daniel P. Berrangé <berrange at redhat.com> wrote:
> >   
> > > On Tue, Jan 12, 2021 at 07:28:45PM +0100, Peter Krempa wrote:  
> > > > On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:    
> > > > > On Tue, 12 Jan 2021 12:35:19 +0100
> > > > > Peter Krempa <pkrempa at redhat.com> wrote  
> 
> [...]
> 
> > > Yeah it is pretty dubious on the QEMU side to have used an "x-" prefix
> > > here at all, when use of this option is mandatory to make migration
> > > work :-(  
> > 
> > if generic consensus is to drop prefix, I can post a QEMU patch to do so
> > and let downstream(s) to carry burden.  
> 
> It really depends on the situation, because the commit messages don't
> seem to describe it satisfactory.
> 
> Basically we don't want to ever use a qemu property knob, which is qemu
> free to change arbitrarily.
> 
> If the property is to be used with any upcoming qemu version we must get
> a guarantee that it will not change. There are two options basically:
> 
> 1) 'x-' is dropped
>  1a) we will use it with qemu-6.0 and later
>     ( everything is clean, but users will have to update qemu to fix it )
I have thought about it some more, (modulo downstream issue)
dropping prefix will effectively exclude old QEMU-(5.0-5.2)
even though feature is available there.

>  1b) we will carry code which will use 'x-' prefixed version from it's
>      inception until qemu-5.2, when we will hard-mask it out and add
>      plenty comments outlining that this is not what we do normally
>      (it will be okay for past releases, since they will not change)
5.2 is not enough, it should be carried till machine type 4.0 exists.
On QEMU side we once 4.0 machine type is removed we can deprecate and
remove no longer needed option so libvirt (with this patches) would see
that it no longer exists and not put it on CLI anymore. Only after that
it probably is ok to drop code for it.

> 
> 2) qemu declares the option stable with the 'x-' prefix
>    We'll require that any place even in the code which declares the
>    option has an appropriate comment preventing anybody from changing
>    it.
> 
>    We'll then add also cautionary comments discouraging use of it.
I've just resent v2 of QEMU patch that incorporates your suggestions.

> 
> 3) qemu fixes the issue without libvirt's involvment
if it were possible the option, I'd go for it in the first place.
unfortunately, it's too late for it now.
 
> For us really 1a) and 3 is acceptable without any comments. Other
> options will require extraordinary measures to prevent using this as
> prior art in using any other x-prefixed features from qemu.
> 
> in 1a) case, downstreams can obviously backport the qemu patch renaming
> the feature and libvirt will require no change at all
> 
> Now the question is whether we want to make migration work between the
> affected releases which will depend what to use.
If we can help it, then yes.
That's why I resent QEMU patch keeping 'x-' prefix (with your feedback included).