Re: [libvirt] Cpu Modeling

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.