qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu devel] disable shared memory is not available wit


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary
Date: Wed, 01 Apr 2015 19:31:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 04/01/2015 07:20 PM, Eric Blake wrote:
On 04/01/2015 10:11 AM, Marcel Apfelbaum wrote:
On 04/01/2015 06:53 PM, Markus Armbruster wrote:
Marcel Apfelbaum <address@hidden> writes:
[...]
I noticed something weird. I cannot actually create an instance of
machine
or get a reference to current_machine in order to query its properties!

It seems that util/qemu-config is used by qemu-img which obviously
does not have a current machine nor the means to create it.

So I have no way to create QOM objects for introspection :(.

You'd have to do something like

    desc[] = generic entries + the machine's entries

where the latter is empty outside qemu proper.
Hmm! So I will loose with some dignity.
I'll keep the properties of the base "machine" on a static array
and *only* per-machine properties dynamic and I loose them.


For 2.3, I recommend to do *only* generic entries.  Specifically,
*exactly* the entries we had before we cleared out
qemu_machine_opts.desc[].
I submitted:
   [PATCH for-2.3] util/qemu-config" fix regression of
qmp_query_command_line_options
which includes both base-machine/per-machine properties.
Is it that bad? qmp can query it and even the new options will work
if qmp decides to set them. Can you have a look?

The problem is that the per-machine properties are ALSO advertised even
on machines where they do not work, which means you could be lying to
libvirt if it needs to know if a specific per-machine option is present.
  It would indeed be more conservative for 2.3 to advertise ONLY the
generic options, so even though I already reviewed your patch, you may
want to respin to incorporate the more conservative approach by dropping
the advertising of any machine-specific option (as that is no worse than
what we had before - better to not advertise a feature than to advertise
something we don't actually support).
OK I'll send it shortly

Thanks,
Marcel


1. You have a QemuOpts problem that is actually pretty common: how to
accept a few fixed parameters plus a bunch of parameters that are
specific to the value of one of the fixed parameters (the
discriminator, in your case "type").
Yes, but is more than that:
per-type properties are not static, you cannot find them before creating
an actual QOM object, and that is not possible.

We could have a per-machine static options array that will be loaded
at init time into object properties... ugly.

But we can avoid worrying about the ugliness or alternatives for solving
that until 2.4.  For 2.3, all we need to focus on is avoiding the
regression.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]