On Thu, Sep 29, 2016 at 15:51:58 -0300, Eduardo Habkost wrote:
On Thu, Sep 29, 2016 at 04:21:07PM +0200, Jiri Denemark wrote: [...]
Slightly related, I don't think we have a way to list CPU features supported by QEMU over QMP, do we? "-cpu ?" will show them all, but I couldn't find a QMP command that would give me the same list.
device-list-properties should return all the properties you can set. But I recommend that you don't make libvirt set any of the properties in the list unless: 1) you know what it does; or 2) it is returned by a query-cpu-model-expansion call.
The use case was for pre-checking whether all CPU features specified in domain XML are supported by current QEMU binary. What parameters would I need to use for device-list-properties? And would it work with -machine none?
You just need the right QOM type name (in x86 it is "<model>-x86_64-cpu" or "<model>-i386-cpu"). I will send a patch that includes a "qom-type" field in CpuDefinitionInfo (query-cpu-definitions) so you know what's the right QOM type name to query.
Hmm, it doesn't seem to work (I tried both -machine none and -machine pc): (QEMU) device-list-properties typename=SandyBridge-x86_64-cpu {"error": {"class": "GenericError", "desc": "Can't list properties of device 'SandyBridge-x86_64-cpu'"}} Anyway, is the list of properties expected to depend on the CPU model? If not, wouldn't a simple query-cpu-properties returning a list of properties QEMU understands be good enough? The list would be pretty similar to what -cpu ? returns. It would help us provide a better error in case a user asks for a CPU features that is not supported by their QEMU binary, and it would also help us translate the result of query-cpu-model-expansion; as you probably know, we use older spellings for some CPU features (e.g., pclmulqdq vs. pclmuldq).
I think device-list-properties won't work with an abstract base type like "x86_64-cpu" or "i386-cpu".
Right: (QEMU) device-list-properties typename=x86_64-cpu {"error": {"class": "GenericError", "desc": "Parameter 'name' expects non-abstract device type"}}
But I think it's better query the right class name for the CPU model you plan to use, anyway (this way architecture code will be able to have different CPU models supporting different sets of options, if necessary).
I see, this make sense. Although a generic query-cpu-properties would still be useful for giving us the translation table between new and old features names. Jirka