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

Re: [libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions



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 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>
> > > > ---
> > > >  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


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