From: Markus Armbruster <armbru@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: bazulay@redhat.com, juzhang@redhat.com, qemu-devel@nongnu.org,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
Date: Fri, 14 May 2010 10:50:40 +0200 [thread overview]
Message-ID: <m3pr0yq333.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <4BEC031D.6020506@redhat.com> (Avi Kivity's message of "Thu, 13 May 2010 16:48:13 +0300")
Avi Kivity <avi@redhat.com> writes:
> On 05/05/2010 10:11 PM, Luiz Capitulino wrote:
>> One of the most important missing feature in QMP today is its
>> supported commands documentation.
>>
>> The plan is to make it part of self-description support, however
>> self-description is a big task we have been postponing for a
>> long time now and still don't know when it's going to be done.
>>
>> In order not to compromise QMP adoption and make users' life easier,
>> this commit adds a simple text documentation which fully describes
>> all QMP supported commands.
>>
>> This is not ideal for a number of reasons (harder to maintain,
>> text-only, etc) but does improve the current situation.
[...]
>> +migrate_set_downtime
>> +--------------------
>> +
>> +Set maximum tolerated downtime (in seconds) for migrations.
>> +
>> +Arguments:
>> +
>> +- "value": maximum downtime (json-number)
>> +
>> +Example:
>> +
>> +{ "execute": "migrate_set_downtime", "arguments": { "value": 60 } }
>>
>
> The example doesn't match reality well, suggest 0.1.
>
> Would have been nicer as migrate_set_parameters downtime: 0.1, we can
> do that when we add more parameters.
I like the idea.
>> +
>> +migrate_set_speed
>> +-----------------
>> +
>> +Set maximum speed for migrations.
>> +
>> +Arguments:
>> +
>> +- "value": maximum speed (json-number)
>> +
>> +Example:
>> +
>> +{ "execute": "migrate_set_speed", "arguments": { "value": 1024 } }
>>
>
> Oh, we do have more.
>
> Please document the units for this value (bits per second)?
bytes per second?
>> +pmemsave
>> +--------
>> +
>> +Save to disk physical memory dump starting at 'val' of size 'size'.
>> +
>> +Arguments:
>> +
>> +- "val": the starting address (json-int)
>>
>
> Why "val" instead of "address" or "physical-address"?
>
>> +- "size": the memory size (json-int)
>>
>
> In bytes.
All sizes are in bytes. Any exceptions are bugs.
That said, it's okay for reference documentation to repeat such things
over and over.
[...]
>> +query-pci
>> +---------
>> +
>> +PCI buses and devices information.
>> +
>> +The returned value is a json-array of all buses. Each bus is represented by
>> +a json-object, which has a key with a json-array of all PCI devices attached
>> +to it. Each device is represented by a json-object.
>> +
>> +The bus json-object contains the following:
>> +
>> +- "bus": bus number (json-int)
>> +- "devices": a json-array of json-objects, each json-object represents a
>> + PCI device
>> +
>> +The PCI device json-object contains the following:
>> +
>> +- "bus": identical to the parent's bus number (json-int)
>> +- "slot": slot number (json-int)
>> +- "function": function number (json-int)
>>
>
> Would have been nicer as a nested object (list of buses, each
> containing a list of slots, each containing a list of functions).
We have a list of buses, each containing a list of device functions.
Not sure the additional level of nesting you propose buys us anything.
I figure we can still change this if we want. libvirt uses info pci
only with pre-0.12 QEMU, over the human monitor.
>> +- "class_info": a json-object containing:
>> + - "desc": device class description (json-string, optional)
>> + - "class": device class number (json-int)
>> +- "id": a json-object containing:
>> + - "device": device ID (json-int)
>> + - "vendor": vendor ID (json-int)
>> +- "irq": device's IRQ if assigned (json-int, optional)
>>
>
> Please note here that the OS may ignore it, so may not be authoritative.
>
>> +- "qdev_id": qdev id string (json-string)
>> +- "pci_bridge": It's a json-object, only present if this device is a
>> + PCI bridge, contains:
>> + - "bus": bus number (json-int)
>> + - "secondary": secondary bus number (json-int)
>> + - "subordinate": subordinate bus number (json-int)
>> + - "io_range": a json-object with memory range information (json-int)
>>
>
> Object or int?
Delete "(json-int)", add suitable "see below".
>> + - "memory_range": a json-object with memory range information (json-int)
>>
> Object or int?
Delete "(json-int)", add suitable "see below".
>> + - "prefetchable_range": a json-object with memory range
>> + information (json-int)
>>
>
> Format not understood.
Delete "(json-int)", add suitable "see below".
>> + - "devices": a json-array of PCI devices if there's any attached (optional)
>>
>
> What is the format of an array element?
Yes, that's not clear here.
[...]
next prev parent reply other threads:[~2010-05-14 8:50 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 19:11 [Qemu-devel] [PATCH v2 0/2]: QMP: Commands doc Luiz Capitulino
2010-05-05 19:11 ` [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc Luiz Capitulino
2010-05-12 16:48 ` Markus Armbruster
2010-05-12 21:17 ` Luiz Capitulino
2010-05-13 7:01 ` Markus Armbruster
2010-05-13 13:15 ` Luiz Capitulino
2010-05-14 11:29 ` Kevin Wolf
2010-05-13 13:48 ` Avi Kivity
2010-05-13 14:55 ` Luiz Capitulino
2010-05-13 15:01 ` Daniel P. Berrange
2010-05-13 16:23 ` Avi Kivity
2010-05-13 21:57 ` Luiz Capitulino
2010-05-14 8:33 ` Markus Armbruster
2010-05-14 16:42 ` Avi Kivity
2010-05-14 17:06 ` Markus Armbruster
2010-05-13 15:05 ` Avi Kivity
2010-05-14 8:39 ` Markus Armbruster
2010-05-14 15:07 ` Luiz Capitulino
2010-05-14 8:50 ` Markus Armbruster [this message]
2010-05-14 15:43 ` Avi Kivity
2010-05-14 17:03 ` Markus Armbruster
2010-05-14 17:09 ` Avi Kivity
2010-05-17 8:27 ` Markus Armbruster
2010-05-17 9:09 ` Avi Kivity
2010-05-17 11:19 ` Markus Armbruster
2010-05-17 18:01 ` Anthony Liguori
2010-05-17 19:21 ` Gerd Hoffmann
2010-05-18 6:55 ` Avi Kivity
2010-05-14 22:54 ` Luiz Capitulino
2010-05-15 6:19 ` Avi Kivity
2010-05-17 8:27 ` Markus Armbruster
2010-05-17 18:10 ` Anthony Liguori
2010-05-17 18:12 ` Avi Kivity
2010-05-18 9:51 ` Markus Armbruster
2010-05-18 12:45 ` Luiz Capitulino
2010-05-14 8:52 ` Markus Armbruster
2010-05-14 16:52 ` [Qemu-devel] " Jan Kiszka
2010-05-14 17:01 ` Avi Kivity
2010-05-14 17:02 ` Avi Kivity
2010-05-14 17:08 ` Jan Kiszka
2010-05-14 17:12 ` Avi Kivity
2010-05-14 23:10 ` Luiz Capitulino
2010-05-15 8:42 ` Jan Kiszka
2010-05-17 13:22 ` Luiz Capitulino
2010-05-18 11:21 ` Markus Armbruster
2010-05-18 12:48 ` Luiz Capitulino
2010-05-05 19:11 ` [Qemu-devel] [PATCH 2/2] Monitor: Drop QMP documentation from code Luiz Capitulino
-- strict thread matches above, loose matches on Subject: below --
2010-04-30 17:03 [Qemu-devel] [PATCH 0/2] QMP: Commands doc Luiz Capitulino
2010-04-30 17:03 ` [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc Luiz Capitulino
2010-05-03 16:24 ` Markus Armbruster
2010-05-04 21:58 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3pr0yq333.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=bazulay@redhat.com \
--cc=juzhang@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.