On Mon, May 09, 2016 at 02:05:05PM +0200, David Hildenbrand wrote: > > On Mon, May 09, 2016 at 10:54:53AM +0200, David Hildenbrand 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. > > > > +# @unavailable-features: List of properties that prevent the CPU > > > > +# model from running in the current host, > > > > +# if @runnable is false. Optional. > > > > +# Since 2.6. > > > > > > Just FYI, on other architectures (e.g. s390x), other conditions (e.g. cpu > > > generation) also define if a CPU model is runnable, so the pure availability of > > > features does not mean that a cpu model is runnable. > > > > > > We could have runnable=false and unavailable-features being an empty list. > > > > Even on those cases, can't the root cause be mapped to a QOM > > property name (e.g. "cpu-generation"), even if it's property that > > can't be changed by the user? > > In the current state, no. But it could be implemented by s390x in the future, if it's considered useful, right? > > So I think for runnable=false: > a) unavailable-features set -> can be made runnable > b) unavailable-features not set -> cannot be made runnable > > would be enough. I understand it would be enough, but I would like to at least define semantics that would make sense for all architectures in case it gets implemented in the future. Would the proposal below make sense? > > > > We could replace this with something more generic, like: > > > > @runnability-blockers: List of attributes that prevent the CPU > > model from running in the current host. > > > > 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 the CPU model can never run > > in the current host. 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. > > > > (I am looking for a better name than "runnability-blockers"). > > > > > > David > -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list