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