Thread (29 messages) 29 messages, 4 authors, 2021-12-08

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

From: Cornelia Huck <cohuck@redhat.com>
Date: 2021-12-07 15:56:32
Also in: kvm

On Tue, Dec 07 2021, Jason Gunthorpe [off-list ref] wrote:
On Tue, Dec 07, 2021 at 11:50:47AM +0100, Cornelia Huck wrote:
quoted
On Mon, Dec 06 2021, Jason Gunthorpe [off-list ref] wrote:
quoted
On Fri, Dec 03, 2021 at 11:06:19AM -0700, Alex Williamson wrote:
quoted
quoted
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.
Absolutely, as soon as QEMU support is made non-experimental, this needs
to be stable.
quoted
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.
Honestly, I regret ever acking this and the QEMU part. Maybe the history
of this and the archived discussions are instructive to others so that
they don't repeat this :/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help