| Message ID | 1465243543-889-5-git-send-email-ehabkost@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jun 06, 2016 at 17:05:41 -0300, Eduardo Habkost wrote: > 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. The commit message still talks about both "runnable" and "unavailable-features" fields even though the former has been removed in version 2 of the series. Jirka
On Thu, Jun 09, 2016 at 03:54:01PM +0200, Jiri Denemark wrote: > On Mon, Jun 06, 2016 at 17:05:41 -0300, Eduardo Habkost wrote: > > 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. > > The commit message still talks about both "runnable" and > "unavailable-features" fields even though the former has been removed in > version 2 of the series. Oops, thanks for pointing it out. Updated to: qmp: Add runnability information to query-cpu-definitions Add a new optional field to query-cpu-definitions schema: "unavailable-features". It will contain a list of QOM properties that prevent the CPU model from running in the current host.
Eduardo Habkost <ehabkost@redhat.com> 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@linux.vnet.ibm.com> > Cc: Michael Mueller <mimu@linux.vnet.ibm.com> > Cc: Christian Borntraeger <borntraeger@de.ibm.com> > Cc: Cornelia Huck <cornelia.huck@de.ibm.com> > Cc: Jiri Denemark <jdenemar@redhat.com> > Cc: libvir-list@redhat.com > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > --- > 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". > +# 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@redhat.com>
On Wed, Jun 22, 2016 at 11:00:47AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabkost@redhat.com> 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@linux.vnet.ibm.com> > > Cc: Michael Mueller <mimu@linux.vnet.ibm.com> > > Cc: Christian Borntraeger <borntraeger@de.ibm.com> > > Cc: Cornelia Huck <cornelia.huck@de.ibm.com> > > Cc: Jiri Denemark <jdenemar@redhat.com> > > Cc: libvir-list@redhat.com > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > > --- > > 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. > > > +# 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@redhat.com> Thanks!
Eduardo Habkost <ehabkost@redhat.com> writes: > On Wed, Jun 22, 2016 at 11:00:47AM +0200, Markus Armbruster wrote: >> Eduardo Habkost <ehabkost@redhat.com> 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@linux.vnet.ibm.com> >> > Cc: Michael Mueller <mimu@linux.vnet.ibm.com> >> > Cc: Christian Borntraeger <borntraeger@de.ibm.com> >> > Cc: Cornelia Huck <cornelia.huck@de.ibm.com> >> > Cc: Jiri Denemark <jdenemar@redhat.com> >> > Cc: libvir-list@redhat.com >> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> >> > --- >> > 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@redhat.com> > > Thanks!
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 +# 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:
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@linux.vnet.ibm.com> Cc: Michael Mueller <mimu@linux.vnet.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Jiri Denemark <jdenemar@redhat.com> Cc: libvir-list@redhat.com Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- 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(-)