qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 8/9] vl: add -query-capabilities


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 8/9] vl: add -query-capabilities
Date: Tue, 20 Mar 2012 16:39:21 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Mar 19, 2012 at 10:09:22AM -0500, Anthony Liguori wrote:
> This dumps the results of query-version, query-commands, and
> query-config-capabilities into a single JSON object on stdout.
> 
> Signed-off-by: Anthony Liguori <address@hidden>

What about a mode where no machine and devices are initialized at all,
but where config files are (optionally) loaded[1] and QMP commands can
be run?

It looks like too much work for 1.1, but I would like to see this
eventually. This would be the starting point for the day we would be
able to run an "empty" Qemu process, probe for features, set up
everything using QMP, and then start the actual virtual machine.

[1] I am asking for this specifically because I know libvirt will need
to probe for some things _after_ loading the config files. This is the
case for the cpudefs, but it may be true for other features and
capabilities too (probing for machine-type info would need it too, if we
moved them to config files some day).


That leads to another question: would it be acceptable to include data
that is depends on the loaded config files inside the
-query-config-capabilities output? (for example, the list of CPU models)
Or do you want to make -query-capabilities independent from the loaded
config data?

Let me try to explain the use case: some configuration options are
high-level and enable and disable a feature as a whole, but management
may want to know what are the low-level details that result from a
specific configuration combination. -writeconfig could help, but it
won't write that low-level data, it will write only the high-level
config it had read.

Example: you are going to ask Qemu to set up a specific CPU
cores/threads topology using "-smp", but then you want to know how
exactly the CPUID topology leafs will look like when you do that. You
_could_ calculate the resulting bits yourself based on your "-smp"
parameter (as the calculation is deterministic), but it would just
duplicate the CPUID generation logic that's already inside Qemu.

-- 
Eduardo



reply via email to

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