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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list