qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 4/6] qmp: Add runnability information to quer


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 4/6] qmp: Add runnability information to query-cpu-definitions
Date: Thu, 23 Jun 2016 09:10:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eduardo Habkost <address@hidden> writes:

> On Wed, Jun 22, 2016 at 11:00:47AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> 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 <address@hidden>
>> > Cc: Michael Mueller <address@hidden>
>> > Cc: Christian Borntraeger <address@hidden>
>> > Cc: Cornelia Huck <address@hidden>
>> > Cc: Jiri Denemark <address@hidden>
>> > Cc: address@hidden
>> > Signed-off-by: Eduardo Habkost <address@hidden>
>> > ---
>> > 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 <address@hidden>
>
> Thanks!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]