| Message ID | 1332169763-30665-9-git-send-email-aliguori@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 03/19/12 16:09, Anthony Liguori wrote: > This dumps the results of query-version, query-commands, and > query-config-capabilities into a single JSON object on stdout. I think libvirt needs a query-devices too. cheers, Gerd
On Tue, Mar 20, 2012 at 08:49:11AM +0100, Gerd Hoffmann wrote: > On 03/19/12 16:09, Anthony Liguori wrote: > > This dumps the results of query-version, query-commands, and > > query-config-capabilities into a single JSON object on stdout. > > I think libvirt needs a query-devices too. Currently we get capability like info in the following areas: * List of CPUs: $QEMU -cpu ? * List of machine types: $QEMU -M ? * List of devices & properties: $QEMU -device ? \ -device pci-assign,? \ -device virtio-blk-pci,? \ -device virtio-net-pci,? \ -device scsi-disk,? As well as 80 odd other pieces of information[1] via -help, but lets not get side tracked by those right now. What is proposed so far is a good start, we can iteratively build on. If we can get the above commands into JSON format too, that'd be nice so that we can have one parser to rule them all. Regards, Daniel [1] See the comments in the enum here for details of what we get from -help http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_capabilities.h;hb=HEAD
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 <aliguori@us.ibm.com> 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.
diff --git a/qemu-options.hx b/qemu-options.hx index 584dc76..4d760d8 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2710,6 +2710,10 @@ the @var{simple} tracing backend. @end table ETEXI +DEF("query-capabilities", 0, QEMU_OPTION_query_capabilities, + "-query-capabilities print QEMU capabilities and exit\n", + QEMU_ARCH_ALL) + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table diff --git a/vl.c b/vl.c index 5337e58..88626aa 100644 --- a/vl.c +++ b/vl.c @@ -2265,6 +2265,29 @@ int qemu_init_main_loop(void) return main_loop_init(); } +static void qemu_print_capabilities(void) +{ + QObject *version, *commands, *config; + QDict *dict; + QString *json; + + qmp_marshal_input_query_version(NULL, NULL, &version); + qmp_marshal_input_query_commands(NULL, NULL, &commands); + qmp_marshal_input_query_config_capabilities(NULL, NULL, &config); + + dict = qdict_new(); + qdict_put_obj(dict, "version", version); + qdict_put_obj(dict, "commands", commands); + qdict_put_obj(dict, "config", config); + + json = qobject_to_json_pretty(QOBJECT(dict)); + + printf("%s\n", qstring_get_str(json)); + + QDECREF(json); + QDECREF(dict); +} + typedef struct QemuOptions { QEMUMachine *machine; @@ -3123,6 +3146,10 @@ static void qemu_parse_option(int index, const char *optarg, QemuOptions *option fclose(fp); break; } + case QEMU_OPTION_query_capabilities: + qemu_print_capabilities(); + exit(0); + break; default: os_parse_cmd_args(index, optarg); }
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 <aliguori@us.ibm.com> --- qemu-options.hx | 4 ++++ vl.c | 27 +++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 0 deletions(-)