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.
Jirka