Re: [RFC v3] VFIO Migration

[Cornelia Huck <cohuck@redhat.com>]

On Wed, 11 Nov 2020 15:48:50 +0000
Daniel P. Berrangé <berrange@redhat.com> 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. 

For mdev devices, we could have something similar to versioned machine
types by introducing versioned mdev types. (Which would fit well with
mdev types having to match strictly for migration to be possible.)

For other use cases, we would need to introduce a new construct.