From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36457 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCup1-0003Xv-I2 for qemu-devel@nongnu.org; Fri, 14 May 2010 09:21:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCuoy-00028J-6W for qemu-devel@nongnu.org; Fri, 14 May 2010 09:20:58 -0400 Received: from david.siemens.de ([192.35.17.14]:16539) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCuox-00027f-QE for qemu-devel@nongnu.org; Fri, 14 May 2010 09:20:56 -0400 From: Jan Kiszka Date: Fri, 14 May 2010 15:20:44 +0200 Message-Id: Subject: [Qemu-devel] [PATCH 0/8] Basic device state visualization List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Anthony Liguori Cc: Avi Kivity , Juan Quintela , Markus Armbruster , Luiz Capitulino While recently fixing the SCSI reset issues, I once again had the need for displaying the state of involved devices. So far the common approach is to attach gdb to qemu (or even inject some printf). But that time I hacked up a 30-minute patch to dump the vmstate of any (fully converted) qdev device. This series now lays the ground for more sophisticated visulization. It adds the monitor command 'device_show ', freezes the vmstate of the addressed device, sticks it into a QMP dict, and either transmit this via QMP or pretty-prints it on a monitor console. Some example: (qemu) device_show /i440FX-pcihost/pci.0/piix3-usb-uhci dev: piix3-usb-uhci, id "" dev. version_id: 00000002 config: a0 7d d1 00 00 00 00 00 - b0 7e d1 00 00 00 00 00 ... irq_state: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 num_ports_vmstate: 02 ports[00]. ctrl: 0083 ports[01]. ctrl: 0080 cmd: 00c1 status: 0000 intr: 0000 frnum: 0077 fl_base_addr: 0fffc000 sof_timing: 40 status2: 00 frame_timer: 0000000000cb2bd0 Basically, this is the level of support I recently saw in a demonstration of some commercial simulator as well. We are just lacking support for the yet unconverted devices. And I think we can even do better on the long term, e.g. by annotating state variables that contain flags, or by pretty-printing buffers like the PCI config space, or... Let's give this a start, I bet it will be helpful while adding complex device models like AHCI or EHCI. Looking forward to feedback! Jan Kiszka (8): qdev: Allow device addressing via 'driver.instance' Add base64 encoder/decoder Add QBuffer monitor: Add basic device state visualization qmp: Teach basic capability negotiation to python example qmp: Fix python helper /wrt long return strings Add QLIST_INSERT_TAIL qdev: Add new devices/buses at the tail Makefile | 3 +- Makefile.objs | 4 +- QMP/qmp-shell | 1 + QMP/qmp.py | 2 +- QMP/vm-info | 1 + base64.c | 202 +++++++++++++++++++++++++++++++++++ base64.h | 18 +++ check-qbuffer.c | 172 ++++++++++++++++++++++++++++++ configure | 2 +- hw/hw.h | 2 + hw/qdev.c | 314 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- hw/qdev.h | 2 + qbuffer.c | 116 ++++++++++++++++++++ qbuffer.h | 33 ++++++ qemu-monitor.hx | 16 +++ qemu-queue.h | 9 ++ qjson.c | 16 +++ qobject.h | 1 + 18 files changed, 902 insertions(+), 12 deletions(-) create mode 100644 base64.c create mode 100644 base64.h create mode 100644 check-qbuffer.c create mode 100644 qbuffer.c create mode 100644 qbuffer.h