Re: [RFC v3] VFIO Migration

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 10 Nov 2020 13:14:04 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Tue, 10 Nov 2020 09:53:49 +0000
> Stefan Hajnoczi <stefanha@redhat.com> wrote:

> > Device models supported by an mdev driver and their details can be read from
> > the migration_info.json attr. Each mdev type supports one device model. If a
> > parent device supports multiple device models then each device model has an
> > mdev type. There may be multiple mdev types for a single device model when they
> > offer different migration parameters such as resource capacity or feature
> > availability.
> > 
> > For example, a graphics card that supports 4 GB and 8 GB device instances would
> > provide gfx-4GB and gfx-8GB mdev types with memory=4096 and memory=8192
> > migration parameters, respectively.  
> 
> 
> I think this example could be expanded for clarity.  I think this is
> suggesting we have mdev_types of gfx-4GB and gfx-8GB, which each
> implement some common device model, ie. com.gfx/GPU, where the
> migration parameter 'memory' for each defaults to a value matching the
> type name.  But it seems like this can also lead to some combinatorial
> challenges for management tools if these parameters are writable.  For
> example, should a management tool create a gfx-4GB device and change to
> memory parameter to 8192 or a gfx-8GB device with the default parameter?

I would expect that the mdev types need to match in the first place.
What role would the memory= parameter play, then? Allowing gfx-4GB to
have memory=8192 feels wrong to me.

(...)

> > An open mdev device typically does not allow migration parameters to be changed
> > at runtime. However, certain migration/params attrs may allow writes at
> > runtime. Usually these migration parameters only affect the device state
> > representation and not the hardware interface. This makes it possible to
> > upgrade or downgrade the device state representation at runtime so that
> > migration is possible to newer or older device implementations.  

This refers to generation of device implementations, but not to dynamic
configuration changes. Maybe I'm just confused by this sentence, but
how are we supposed to get changes while the mdev is live across?

> 
> 
> Which begs the question of how we'd determine which can be modified
> runtime...  Thanks,
> 
> Alex
> 
> 
And this as well. Do we need different categories?