Re: [RFC v3] VFIO Migration

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Nov 16, 2020 at 01:48:58PM +0100, Gerd Hoffmann wrote:
> > > In validating QEMU migration compatibility we merely compare the
> > > versioned machine type.
> > 
> > Thinking more about this, maybe the big picture is:
> > 
> > Today the managment tool controls the variables in the migration (the
> > device configuration). It has knowledge of the VMM, can set a machine
> > type, apply a device configuration on top, and then migrate safely.
> > 
> > VFIO changes this model because VMMs and management tools do not have
> > knowledge of specific device implementations. The device implementation
> > is a new source of variables in the migration and the management tool no
> > longer has the full picture.
> 
> Well.  We actually have the variables.  They are device properties.
> Then the qemu compat properties basically map a machine type to a
> set of device properties.  That way we hide the complexity inside
> qemu.  The management apps have to deal with the (versioned) machine
> type only.
> 
> I guess now we have to decide whenever we want expose the individual
> variables or whenever we want something like "profiles", i.e. basically
> a set of variables with a name attached.
> 
> At the end of the day it is a complexity vs. flexibility tradeoff ...
> 
> take care,
>   Gerd

BTW it's not too bad if, for starters, we are doing exactly what we are
used to be doing, just ask vendors to supply the list all variables and
include it in the QEMU code. Has a benefit of limiting our support
matrix so we can make initial protocol changes with reasonable certainty
they do not break devices.  Once number of supported devices grows we
can think of sane ways to relax that...

-- 
MST