[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:11:46 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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?
[...]
Big job, though.
You lost me... you are talking about QAPI that I have no knowledge about,
and I still don't see how I can create instances of QOM objects in the context
of qemu-config.
Very high level summary:
0. We use QemuOpts to define our command line. The definition is
*incomplete*. The missing parts are left to code.
query-command-line-options can't see them.
OK
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.
2. We've solved this in several different ways, and all of them make
query-command-line-options useless.
Got it
3. Same problem exists in QMP, and we have a decent solution there,
based on QAPI.
OK
4. We'll soon have QMP/QAPI introspection.
And then we can query a 'living' object's properties
5. If we used a QAPI schema to define our command line, we could do a
more complete job (because it's more expressive), and we'd get
introspection basically for free.
If the QAPI schema will include *all* properties *per* machine type, sure.
6. #5 would be a big job, though.
Less confused now?
Much better, thanks!
Marcel
[...]
- Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary, (continued)
Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary, Markus Armbruster, 2015/04/01