Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > On Tue, May 10, 2016 at 10:23:16AM +0200, Markus Armbruster wrote: >> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: >> >> > On Mon, May 09, 2016 at 09:20:15AM -0600, Eric Blake wrote: >> >> On 05/06/2016 12:11 PM, 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. >> >> > >> >> > 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> >> >> > --- >> >> > qapi-schema.json | 10 +++++++++- >> >> > 1 file changed, 9 insertions(+), 1 deletion(-) >> >> > >> >> > diff --git a/qapi-schema.json b/qapi-schema.json >> >> > index 54634c4..450e6e7 100644 >> >> > --- a/qapi-schema.json >> >> > +++ b/qapi-schema.json >> >> > @@ -2948,11 +2948,19 @@ >> >> > # Virtual CPU definition. >> >> > # >> >> > # @name: the name of the CPU definition >> >> > +# @runnable: true if the CPU model is runnable using the current >> >> > +# machine and accelerator. Optional. Since 2.6. >> >> >> >> You've missed 2.6. Also, the typical spelling for a per-member >> >> designation is '(since 2.7)', not 'Since 2.7' >> > >> > Oops! I meant 2.7, and I didn't notice that it was not using the >> > typical format. I will fix it, thanks. >> > >> >> >> >> Why is it optional? Would it hurt to always be present in qemu new >> >> enough to understand why it is needed? >> > >> > It is optional because not all architectures will return the >> > field. This series implements it only for x86. >> >> Its documentation seems to suggest missing runnable has the same meaning >> as runnable: false. Is that correct? > > No, it means the architecture code doesn't implement the feature > yet and we don't know if the CPU model is runnable or not. > > The day we implement the new field in all architectures, we can > stop making it optional. Please clarify that in the docs. Here's my try: # @runnable: #optional whether the CPU model us usable with the current # machine and accelerator, only present if we know (since 2.6) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list