[Top][All Lists]

[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: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Date: Mon, 24 May 2010 15:22:28 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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.
+- "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.

I don't think that qdev device names and paths are something we have to worry much about changing over time since they reflect logical bus layout. They should remain static provided the devices remain static.

The qdev properties are a different matter entirely. A command like 'info qdm' would be potentially difficult to support as part of QMP but the proposed command's output is actually already part of a backward compatible interface (vmstate).


Anthony Liguori

+The element object array may be empty, otherwise it can contain
+- json-int objects
+- QMP buffer objects
+- field objects
+- arrays of json-ints, QMP buffers, or field objects
+-> { "execute": "device_show", "arguments": { "path": "isa.0/i8042" } }
+<- { "return": { "device": "i8042", "id": "", "fields":
+                 [ { "name": "kbd", "size": 4, "elems":
+ [ { "name": "write_cmd", "size": 1, "elems": [0] },
+                       { "name": "status", "size": 1, "elems": [25] },
+                       { "name": "mode", "size": 1, "elems": [3] },
+                       { "name": "pending", "size": 1, "elems": [1] }
+                     ] }
+                 ]
+               }
+   }

Looks good. I am only worried about long term stability and documentation.

reply via email to

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