Re: [RFC v3] VFIO Migration

[Daniel P . Berrangé]

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:
> > > "allowed_values"
> > >    The list all values that the device implementation accepts for this 
> > > migration
> > >    parameter. Integer ranges can be described using "<min>-<max>" strings.
> > > 
> > >    Examples: ['a', 'b', 'c'], [1, 5, 7], ['0-255', 512, '1024-2048'], 
> > > [true]
> > > 
> > >    This member is optional. When absent, any value suitable for the type 
> > > may be
> > >    given but the device implementation may refuse certain values.
> > 
> > I'd rather make this simpler:
> > 
> > - remove allowed_values for strings.  Effect: discourages using strings as
> > enums, leaving them only for free-form values such as vendor name or model
> > name.
> 
> And introduce an enum type?
> 
> > - remove allowed_values for bools.  If off_value is absent the only allowed
> > value is init_value.  If off_value is present, both true and false are
> > allowed (and !off_value is the "on_value", so to speak).
> 
> Makes sense.
> 
> > - change allowed_values into allowed_min and allowed_max for int values.
> > Advantage: avoids having to parse strings as ranges.  Disadvantage: removes
> > expressiveness (cannot say "x must be a power of two"), but I'm not sure
> > it's worth the extra complication.
> 
> 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.

IIUC, in this proposal, it would be more like exploding the machine
type into all its 100's of properties and then comparing each one
individually.

I really prefer the simpler model of QEMU versioned machine types
where compatibility is a simple string comparison, hiding the
100's of individual config parameters.  

Of course there are scenarios where this will lead a mgmt app to
refuse a migration, when it could in fact have permitted it.

eg  consider   pc-i440fx-4.0  and pc-i440fx-5.0 machine types,
which only differ in the value  "foo=7" and "foo=8" respectively.

Now if the target only supported machine type pc-i440fx-5.0, then
with a basic string comparison of machine type versin, we can't
migrate from a host uing pc-i440fx-4.0

If we exploded the machine type into its params, we could see that
we can migrate from pc-i440fx-4.0 to pc-i440fx-5.0, simply by
overriding the value of "foo".

So, yes, dealing with individual params is more flexible, but it
comes at an enourmous cost in complexity to process all the
parameters. I'm not convinced this is a good tradeoff. 


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|