Re: [RFC v3] VFIO Migration

[Stefan Hajnoczi]

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

signature.asc
Description: PGP signature