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