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