[PATCH v2 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

[Michal Privoznik]

On 1/14/21 2:10 PM, Peter Krempa wrote:
> On Thu, Jan 14, 2021 at 13:52:45 +0100, Peter Krempa wrote:
>> On Thu, Jan 14, 2021 at 13:37:23 +0100, Michal Privoznik wrote:
>>> This capability tracks whether memory-backend-file has
>>> "x-use-canonical-path-for-ramblock-id" attribute. Introduced into
>>> QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. While
>>> "x-" prefix is considered experimental or internal to QEMU, the
>>> next commit justifies its use.
>>
>> Since the detection of this feature is not limited to existing qemus, my
>> requirement that qemu must add acknowledgement that
>> "x-use-canonical-path-for-ramblock-id" will be treated as a stable
>> feature from now on and the qemu commit adding that must be mentioned in
>> this commit.

Is there something concrete you have on mind that you want me to write 
there? I thought I added a comment around capability detection that 
justifies its use.

>>
>> The only other way is to limit the feature detection to any released
>> qemu (thus qemu-5.2 and previous), since we still will not get a
>> guarantee that they will not change the flag in the future.
> 
> Let me reiterate the options when this will be acceptable so that we are
> in the clear:
> 
> 1) qemu declares "x-use-canonical-path-for-ramblock-id" stable in code
>     and docs (please cc me on the commit)

I've linked that patch in the cover letter. It was sent already so a 
little too late to CC anybody, sorry

> 
> 2) qemu drops the "x-", and ...
>      2a) we use "use-canonical-path-for-ramblock-id" only with new qemus
>          which have the stable version
>          (this is what we would usually do)

Since I'm failing to document our use of this knob maybe this is the way 
to go.

>      2b) we also add support for "x-use-canonical-path-for-ramblock-id"
>          but detection will be limited to existing releases
> 
> Supporting "x-use-canonical-path-for-ramblock-id" for any future release
> of qemu without a clear declaration that it's considered stable in qemu
> is not acceptable for libvirt.
> 

I think that's what the qemu patch I'm linking in the cover letter does.

Michal