On Thu, May 12, 2016 at 09:19:48AM +0200, Jiri Denemark wrote:
On Wed, May 11, 2016 at 16:35:50 -0300, Eduardo Habkost wrote:
> # @CpuDefinitionInfo:
> #
> # Virtual CPU definition.
> #
> # @name: the name of the CPU definition
> # @runnable: #optional. whether the CPU model us usable with the
s/ us / is /
Thanks!
> # current machine and accelerator. Omitted if we don't
> # know the answer. (since 2.7)
> # @unavailable-features: List of attributes that prevent the CPU
> # model from running in the current host.
> # (since 2.7)
> #
> # @unavailable-features is 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.
Any chance this could be extended to provide data about every single
machine type rather than just the current one?
I want to do that, but it would require reorganizing
CPU/machine/accelerator code to allow probing to happen without
depending on global data (including: machine state, accelerator
state, global properties). This will probably take a while to be
implemented.
But: at least for x86, we now guarantee that runnability
shouldn't change depending on the machine-type. If a CPU model is
runnable with a machine version, it should be runnable with other
versions of the same family.
That guarantee is not documented above because I still don't know
if we can enforce it on all other architectures.
--
Eduardo