> > >
> > > 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?
Yes, we could fit that into read-only properties if we would ever need it
(like cpu-generation you mentioned and cpu-ga-level - both will always be
read-only).
However we could come up with more optional fields for that in the future.
(like unsupported-values or sth. like that). I actually prefer
unavailable-features over runnability-blockers.
>
> 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?
Yes, I think so. However to really make good hints, upper layers would most
likely need more information about the exact problem with a property -
maybe something like an enum value per problematic property.
(UNAVAILABLE_FEATURE, VALUE_TOO_BIG, VALUE_TOO_SMALL, UNSUPPORTED_VALUE) ...
> >
> > 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").
> >
Not sure which approach would be better.
David