Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
> On Wed, Jun 22, 2016 at 11:00:47AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
>>
>> > Extend query-cpu-definitions schema to allow it to return two new
>> > optional fields: "runnable" and "unavailable-features".
>> > "runnable" will tell if the CPU model can be run in the current
>> > host. "unavailable-features" will contain a list of CPU
>> > properties that are preventing the CPU model from running in the
>> > current host.
>> >
>> > Cc: David Hildenbrand <dahi@xxxxxxxxxxxxxxxxxx>
>> > Cc: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx>
>> > Cc: Christian Borntraeger <borntraeger@xxxxxxxxxx>
>> > Cc: Cornelia Huck <cornelia.huck@xxxxxxxxxx>
>> > Cc: Jiri Denemark <jdenemar@xxxxxxxxxx>
>> > Cc: libvir-list@xxxxxxxxxx
>> > Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx>
>> > ---
>> > Changes v1 -> v2:
>> > * Remove @runnable field, non-empty @unavailable-features is
>> > enough to report CPU model as not runnable.
>> > * Documentation updates:
>> > * Changed to "(since 2.7)";
>> > * Add more details about the exact meaning of
>> > unavailable-features, and what it would mean to see
>> > read-only QOM properties in the list, and that
>> > implementations can return "type" if there's
>> > no extra information available;
>> > ---
>> > qapi-schema.json | 23 ++++++++++++++++++++++-
>> > 1 file changed, 22 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/qapi-schema.json b/qapi-schema.json
>> > index 8483bdf..43478e9 100644
>> > --- a/qapi-schema.json
>> > +++ b/qapi-schema.json
>> > @@ -3005,11 +3005,32 @@
>> > # Virtual CPU definition.
>> > #
>> > # @name: the name of the CPU definition
>> > +# @unavailable-features: #optional List of properties that prevent
>> > +# the CPU model from running in the current
>> > +# host. (since 2.7)
>> > +#
>> > +# @unavailable-features is a list of QOM property names that
>> > +# represent CPU model attributes that prevent the CPU from running.
>> > +# If the QOM property is read-only, that means there's no known
>> > +# way to make the CPU model run in the current host. If
>> > +# absolutely no extra information will be returned to explain why
>>
>> Suggest "can be returned".
>
> I believe that "extra information can be returned" will always be
> true (we just need an appropriate property name to represent that
> information). But people writing architecture-specific code are
> free to decide if the extra effort is worth it, or if "type" is
> good enough for them.
Hmm. What about: Implementations that choose not to provide specific
information return the property name "type".
>> > +# the CPU model is not runnable, implementations may simply
>> > +# return "type" as the property name.
>> > +# If the property is read-write, it means that it MAY be possible
>> > +# to run the CPU model in the current host if that property is
>> > +# changed. Management software can use it as hints to suggest or
>> > +# choose an alternative for the user, or just to generate meaningful
>> > +# error messages explaining why the CPU model can't be used.
>> > +# If @unavailable-features is an empty list, the CPU model is
>> > +# runnable using the current host and machine-type.
>> > +# If @unavailable-features is not present, runnability
>> > +# information for the CPU is not available.
>> > #
>> > # Since: 1.2.0
>> > ##
>> > { 'struct': 'CpuDefinitionInfo',
>> > - 'data': { 'name': 'str' } }
>> > + 'data': { 'name': 'str',
>> > + '*unavailable-features': [ 'str' ] } }
>> >
>> > ##
>> > # @query-cpu-definitions:
>>
>> With the commit message tidied up as per your reply to Jiri:
>> Reviewed-by: Markus Armbruster <armbru@xxxxxxxxxx>
>
> Thanks!
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list