Re: [PATCH RFC] vfio: Revise and update the migration uAPI description

From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "cohuck@redhat.com" <cohuck@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"farman@linux.ibm.com" <farman@linux.ibm.com>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH RFC] vfio: Revise and update the migration uAPI description
Date: Wed, 19 Jan 2022 09:18:17 -0400	[thread overview]
Message-ID: <20220119131817.GK84788@nvidia.com> (raw)
In-Reply-To: <20220118125522.6c6bb1bb.alex.williamson@redhat.com>

On Tue, Jan 18, 2022 at 12:55:22PM -0700, Alex Williamson wrote:

> be dead code.  The specification below doesn't propose the
> ARC_SUPPORTED ioctl and userspace is implemented with some vague notion
> that these states may not be implemented, but has no means to test.

BTW, to be clear, we are proposing to include the ARC_SUPPORTED ioctl
immediately, and adopt it in qemu when we implement the P2P support
there. It was just split into a seperate patch for review.

If qemu will attempt to support the optional non-P2P mode (without a
supporting driver yet existing) or simply fail to support migration if
P2P arcs are not supported is up to the qemu team.

It doesn't matter which choice qemu makes to the kernel series.

I also don't care if we write this patch with P2P described as
non-optional - so long as we all understand that when hns's driver
comes along and cannot implement the P2P stuff we have a fully
compatible upgrade path that does not change the migration region
version.

Jason