[PATCH v2 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

Peter Krempa pkrempa at redhat.com
Thu Jan 14 13:10:12 UTC 2021

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.
> 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)

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)
    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.

More information about the libvir-list mailing list