qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Date: Mon, 24 May 2010 22:35:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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<address@hidden>
>>>
>>> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

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