Re: [PATCH RFC v2] vfio: Documentation for the migration region

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Dec 07, 2021 at 11:50:47AM +0100, Cornelia Huck wrote:
> On Mon, Dec 06 2021, Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Fri, Dec 03, 2021 at 11:06:19AM -0700, Alex Williamson wrote:
> 
> >> This is exactly the sort of "designed for QEMU implementation"
> >> inter-operability that I want to avoid.  It doesn't take much of a
> >> crystal ball to guess that gratuitous and redundant device resets
> >> slow VM instantiation and are a likely target for optimization.
> >
> > Sorry, but Linus's "don't break userspace" forces us to this world.
> >
> > It does not matter what is written in text files, only what userspace
> > actually does and the kernel must accommodate existing userspace going
> > forward. So once released qemu forms some definitive spec and the
> > guardrails that limit what we can do going forward.
> 
> But QEMU support is *experimental*, i.e. if it breaks, you get to keep
> the pieces, things may change in incompatible ways. And it is
> experimental for good reason!

And we can probably make an breakage exception for this existing
experimental qemu.

My point was going forward, once we userspace starts to become
deployed, it doesn't matter what we write in these text files and
comments. It only matters what deployed userspace actually does.

> It would mean that we must never introduce experimental interfaces
> in QEMU that may need some rework of the kernel interface, but need
> to keep those out of the tree -- and that can't be in the best
> interest of implementing things requiring interaction between the
> kernel and QEMU.

In general we should not be merging uAPI to the kernel that is so
incomplete as to be unusable. 

I'm sorry, this whole thing from the day the migration stuff was first
merged to include/uapi is a textbook example how not to do things in
the kernel community.

Jason