Re: [RFC v3] VFIO Migration

[Stefan Hajnoczi]

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?

Stefan

signature.asc
Description: PGP signature