On Fri, Sep 30, 2016 at 09:00:15AM +0200, Jiri Denemark wrote:
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'"}}
Oops, we need to remove cannot_destroy_with_object_finalize_yet from the CPU classes, and then this will work.
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 see. I will check if I can fit this information inside query-command-line-options.
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.
If we add the aliases for old names like you sugested on qemu-devel, the old names should be available in the QOM queries, too. If we fix device-list-properties to work with abstract types and add the old names to the QOM property list as aliases (both things we should do eventually, anyway), then a specific query-cpu-properties or query-command-line-options support may be unnecessary. -- Eduardo