Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

Anthony Liguori wrote:
> On 05/22/2010 01:55 PM, Avi Kivity wrote:
>> On 05/22/2010 11:18 AM, Jan Kiszka wrote:
>>> From: Jan Kiszka<jan.kiszka@siemens.com>
>>>
>>> This introduces device_show, a monitor command that saves the vmstate of
>>> a qdev device and visualizes it. QMP is also supported. Buffers are cut
>>> after 16 byte by default, but the full content can be requested via
>>> '-f'. To pretty-print sub-arrays, vmstate is extended to store the start
>>> index name. A new qerror is introduced to signal a missing vmstate. And
>>> it comes with documentation.
>>>
>>> +
>>> +Dump a snapshot of the device state. Buffers are cut after 16 bytes
>>> unless
>>> +a full dump is requested.
>>> +
>>> +Arguments:
>>> +
>>> +- "path": the device's qtree path or unique ID (json-string)
>>
>> This may be ambiguous.
>>
>>> +- "full": report full state (json-bool, optional)
>>
>> Is this needed for QMP?  The client can always truncate it to any length.
>>
>>> +
>>> +Schema of returned object:
>>> +
>>> +{ "device": json-string, "id": json-string, "fields" : [
>>> field-objects ] }
>>> +
>>> +The field object array may be empty, otherwise it consists of
>>> +
>>> +{ "name": json-string, "size": json-int, "elems": [ element-objects ] }
>>> +
>>> +"size" describes the real number of bytes required for a binary
>>> representation
>>> +of a single field element in the array. The actually transfered
>>> amount may be
>>> +smaller unless a full dump was requested.
>>
>> This converts the entire qdev tree into an undocumented stable
>> protocol (the qdev paths were already in this state I believe).  This
>> really worries me.
> 
> N.B. the association with qdev is only in identifying the device.  The
> contents of the device's state are not part of qdev but rather part of
> vmstate.  vmstate is something that we already guarantee to be stable
> since that's required for live migration compatibility.

In contrast to save/loadvm, device_show does not provide a
backward-compatible output. Not only field names can change (as a result
of internal refactoring), fields may even disappear, new ones may pop
up. vmstate makes this transparent for reading of old states, but not
for visualization.

That said, I see no use case yet that would justify the effort for
making state dumps as stable as vmstates.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]