Re: [RFC v3] VFIO Migration

From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: John G Johnson <john.g.johnson@oracle.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	mtsirkin@redhat.com, Yan Zhao <yan.y.zhao@intel.com>,
	quintela@redhat.com, Jason Wang <jasowang@redhat.com>,
	"Zeng, Xin" <xin.zeng@intel.com>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Felipe Franciosi <felipe@nutanix.com>,
	Christophe de Dinechin <dinechin@redhat.com>,
	Thanos Makatos <thanos.makatos@nutanix.com>
Subject: Re: [RFC v3] VFIO Migration
Date: Mon, 16 Nov 2020 10:48:32 +0000	[thread overview]
Message-ID: <20201116104832.GB96297@stefanha-x1.localdomain> (raw)
In-Reply-To: <20201111154850.GG906488@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

On Wed, Nov 11, 2020 at 03:48:50PM +0000, Daniel P. Berrangé wrote:
> On Wed, Nov 11, 2020 at 02:36:15PM +0000, Stefan Hajnoczi wrote:
> > On Tue, Nov 10, 2020 at 12:12:31PM +0100, Paolo Bonzini wrote:
> > > On 10/11/20 10:53, Stefan Hajnoczi wrote:
> In terms of validation I can't help but feel the whole proposal is
> really very complicated.
> 
> In validating QEMU migration compatibility we merely compare the
> versioned machine type.
> 
> IIUC, in this proposal, it would be more like exploding the machine
> type into all its 100's of properties and then comparing each one
> individually.
> 
> I really prefer the simpler model of QEMU versioned machine types
> where compatibility is a simple string comparison, hiding the
> 100's of individual config parameters.  
> 
> Of course there are scenarios where this will lead a mgmt app to
> refuse a migration, when it could in fact have permitted it.
> 
> eg  consider   pc-i440fx-4.0  and pc-i440fx-5.0 machine types,
> which only differ in the value  "foo=7" and "foo=8" respectively.
> 
> Now if the target only supported machine type pc-i440fx-5.0, then
> with a basic string comparison of machine type versin, we can't
> migrate from a host uing pc-i440fx-4.0
> 
> If we exploded the machine type into its params, we could see that
> we can migrate from pc-i440fx-4.0 to pc-i440fx-5.0, simply by
> overriding the value of "foo".
> 
> So, yes, dealing with individual params is more flexible, but it
> comes at an enourmous cost in complexity to process all the
> parameters. I'm not convinced this is a good tradeoff. 

A single standard version number is not enough since there are optional
features and resource capacity (number of queues, memory sizes, etc)
varies between implementations.

At best, a version number can summarize multiple migration parameters,
but it cannot eliminate all of them.

If we don't care about checking compatiblity ahead of time then we can
use just a device model and version, but then migration fails when the
source and destination end up being incompatible.

Since you raised the requirement of checking migration compatibility
ahead of time, I don't see a way to avoid the complexity.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]