Re: [RFC v3] VFIO Migration

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

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:
> > Yes, the current syntax supports sparse ranges and multiple ranges.
> > 
> > The trade-off is that a tool cannot validate inputs beforehand. You need
> > to instantiate the device to see if it accepts your inputs. This is not
> > great for management tools because they cannot select a destination
> > device if they don't know which exact values are supported.
> > 
> > Daniel Berrange raised this requirement in a previous revision, so I
> > wonder what his thoughts are?
> 
> 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.

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.

I'm trying to define a standard interface for exposing migration
compatibility information from device implementations to management
tools, and a general algorithm that management tools can use without
knowledge of specific device implementations.

It is possible to simplify the problem, but we'll lose freedom. For
example, hard coding knowledge of the device implementation into the
management tool eliminates the need for a general migration checking
algorithm. Or we might be able to simplify it by explicitly not
supporting cross-device implementation migration (although that would
place stricter rules on what a new version of an existing device can
change in order to preserve migration compatibility).

I have doubts that these trade-offs can be made without losing support
for use cases that are necessary.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]