Re: [RFC v3] VFIO Migration

[Stefan Hajnoczi <stefanha@redhat.com>]

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

On Wed, Nov 11, 2020 at 03:41:59PM +0000, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > On Wed, Nov 11, 2020 at 12:56:26PM +0000, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > > Orchestrating Migrations
> > > > ------------------------
> > > > In order to migrate a device a *migration parameter list* must first be built
> > > > on the source. Each migration parameter is added to the list if it is in
> > > > effect. For example, the migration parameter list for a device with
> > > > new-feature=off,num-queues=4 would be num-queues=4 if the new-feature migration
> > > > parameter was introduced with the off value disabling its effect.
> > > 
> > > What component builds that list (i.e. what component needs to know the
> > > history that new-feature=off was the default - ah I think you answer
> > > that below).
> > 
> > Yep. Thanks for noting this. I'll need to reorder things so it is clear.
> > 
> > > > The following conditions must be met to establish migration compatibility:
> > > > 
> > > > 1. The source and destination device model strings match.
> > > > 
> > > > 2. Each migration parameter name from the migration parameter list is supported
> > > >    by the destination. For example, the destination supports the num-queues
> > > >    migration parameter.
> > > > 
> > > > 3. Each migration parameter value from the migration parameter list is
> > > >    supported by the destination. For example, the destination supports
> > > >    num-queues=4.
> > > 
> > > Hmm, are combinations of parameter checks needed - i.e. is it possible
> > > that a destination supports    num-queues=4 and  new-feature=on/off -
> > > but only supports new-feature=on when num-queues>2 ?
> > 
> > Yes, it's possible but cannot be expressed in the migration info JSON.
> > 
> > We need to choose a level of expressiveness that will be useful enough
> > without being complex. In the extreme the migration info would contain
> > Turing complete validation expressions (e.g. JavaScript) so that any
> > relationship can be expressed, but I doubt that complexity is needed.
> > The other extreme is just booleans and (opaque) strings for maximum
> > simplicity.
> > 
> > If the syntax is not expressive enough then it's impossible to check
> > migration compatibility without actually creating a new device instance
> > on the destination. Daniel Berrange raised the requirement of checking
> > migration compatibility without creating the device since this helps
> > with selecting a migration destination.
> 
> Right, but my worry isn't the JSON description, it's the set of 3
> conditions above; they need to state that only some combinations need to
> be valid.

Yes, the proposed syntax is simply not expressive enough. The migration
compatibility check will pass and then the destination will refuse to
set up the device (before the device state is transferred).

Any suggestions for a syntax without full-blown arithmetic and logic
expressions?

> > Any ideas for a better syntax?
> 
> I'd be happy with a --param name=value   repeatedly, but also know that
> some option parsers don't like that.

Another wart, Sphinx considers repeated options an error so you cannot
document options using rST option syntax. I remember having this problem
when documenting virtiofsd's command-line options :).

If something comes to mind please let me know. I'm not set on a
particular syntax, but I'd like to choose the one that is both
human-friendly and compatible with option parsers while avoiding
namespace collisions with the device implementation's own options.

Stefan

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