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