On Tue, Feb 01 2022, Alex Williamson [off-list ref] wrote:

On Tue, 01 Feb 2022 13:39:23 +0100
Cornelia Huck [off-list ref] wrote:

quoted

On Tue, Feb 01 2022, Jason Gunthorpe [off-list ref] wrote:

quoted

On Tue, Feb 01, 2022 at 12:23:05PM +0100, Cornelia Huck wrote:  

quoted

On Sun, Jan 30 2022, Yishai Hadas [off-list ref] wrote:
  

quoted

From: Jason Gunthorpe <jgg@nvidia.com>

v1 was never implemented and is replaced by v2.

The old uAPI definitions are removed from the header file. As per Linus's
past remarks we do not have a hard requirement to retain compilation
compatibility in uapi headers and qemu is already following Linus's
preferred model of copying the kernel headers.  

If we are all in agreement that we will replace v1 with v2 (and I think
we are), we probably should remove the x-enable-migration stuff in QEMU
sooner rather than later, to avoid leaving a trap for the next
unsuspecting person trying to update the headers.  

Once we have agreement on the kernel patch we plan to send a QEMU
patch making it support the v2 interface and the migration
non-experimental. We are also working to fixing the error paths, at
least least within the limitations of the current qemu design.  

I'd argue that just ripping out the old interface first would be easier,
as it does not require us to synchronize with a headers sync (and does
not require to synchronize a headers sync with ripping it out...)

quoted

The v1 support should remain in old releases as it is being used in
the field "experimentally".  

Of course; it would be hard to rip it out retroactively :)

But it should really be gone in QEMU 7.0.

Considering adding the v2 uapi, we might get unlucky: The Linux 5.18
merge window will likely be in mid-late March (and we cannot run a
headers sync before the patches hit Linus' tree), while QEMU 7.0 will
likely enter freeze in mid-late March as well. So there's a non-zero
chance that the new uapi will need to be deferred to 7.1.

Agreed that v1 migration TYPE/SUBTYPE should live in infamy as
reserved, but I'm not sure why we need to make the rest of it a big
complicated problem.  On one hand, leaving stubs for the necessary
structure and macros until QEMU gets updated doesn't seem so terrible.
Nor actually does letting the next QEMU header update cause build
breakages, which would probably frustrate the person submitting that
update, but it's not like QEMU hasn't done selective header updates in
the past.  The former is probably the more friendly approach if we
don't outrage someone in the kernel community in the meantime.

Leaving stubs in (while making it clear that v1 is not something you
should use) seems like a good compromise. While we have done selective
headers updates in QEMU in the past, I always found them painful, so I'd
like to avoid that.