Re: [RFC v3] VFIO Migration

[Stefan Hajnoczi]

On Wed, Nov 11, 2020 at 12:48:53PM +0100, Cornelia Huck wrote:
> 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.

Yes, I expected these mdev types to only accept a fixed "memory" value,
but there's nothing stopping a driver author from making "memory" accept
any value.

> > > 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?

This is about dynamic configuration changes. For example, if a field was
forgotten in the device state representation then a migration parameter
can be added to enable the fix. When the parameter is off the device
state is incomplete but migration to old device implementations still
works. An old device can be migrated to a new device implementation with
the parameter turned off. And then you can safely enable the migration
parameter at runtime without powering off the guest because it's purely
a device state representation change, not a hardware interface change
that would disturb the guest.

This is kind of similar to QEMU migration subsections.

Stefan

signature.asc
Description: PGP signature