From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47138 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OG82s-0006ww-Cd for qemu-devel@nongnu.org; Sun, 23 May 2010 06:04:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OG82q-0007g9-34 for qemu-devel@nongnu.org; Sun, 23 May 2010 06:04:34 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:57932) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OG82p-0007fx-Mj for qemu-devel@nongnu.org; Sun, 23 May 2010 06:04:32 -0400 Message-ID: <4BF8FD83.60600@web.de> Date: Sun, 23 May 2010 12:03:47 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1f557b9feb1965a61e64f7166bcf4918bed8d0ec.1274516288.git.jan.kiszka@web.de> <4BF82895.6000706@redhat.com> <4BF8DFF7.5070302@web.de> <4BF8EAFB.2080807@redhat.com> In-Reply-To: <4BF8EAFB.2080807@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE78E24CE6DD25E05236EEAB" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Juan Quintela , Jan Kiszka , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE78E24CE6DD25E05236EEAB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 05/23/2010 10:57 AM, Jan Kiszka wrote: >> Avi Kivity wrote: >> =20 >>> On 05/22/2010 11:18 AM, Jan Kiszka wrote: >>> =20 >>>> From: Jan Kiszka >>>> >>>> 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) >>>> >>>> =20 >>> This may be ambiguous. >>> =20 >> Can your elaborate what precisely is ambiguous? >> =20 >=20 > Can't the user choose the unique ID so that it aliases an unrelated > qtree path? True. I'll swap the search order and document this. Qtree paths should always rule. >=20 > I prefer having mutually exclusive 'path' and 'ref' arguments. That would be unhandy. >=20 >>>> +- "full": report full state (json-bool, optional) >>>> >>>> =20 >>> Is this needed for QMP? The client can always truncate it to any >>> length. >>> =20 >> The effect may not be needed for QMP, but I do need this channel from >> the command line to the monitor pretty-printer. I could just stick >> "full": json-bool back into the return dict, but that would look someh= ow >> strange IMO. >> =20 >=20 > So we could disallow it as a QMP input, but allow it as an HMP input. >=20 >>>> + >>>> +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. >>>> >>>> =20 >>> This converts the entire qdev tree into an undocumented stable protoc= ol >>> (the qdev paths were already in this state I believe). This really >>> worries me. >>> =20 >> Being primarily a debugging tool, device_show exports the entire >> (qdev'ified) vmstates via QMP. Unlike the migration protocol, it does >> not provide something like backward compatibility. >=20 > Should be explicitly documented. All QMP commands should be backwards > and forwards compatible unless noted. >=20 >> This would be >> overkill for the intended purpose (though someone may find a different= >> use case one day). >> =20 >=20 > Even for simply showing things, a GUI may depend on the presence of > certain fields. If we document that the fields may change, a correctly= > written GUI can fall back to a simpler display. >=20 >> I think we have the following options: >> - disable device_show via QMP, limit it to the monitor console >> - declare its output inherently unstable, maybe at least adding the >> vmstate version to each device so that potential QMP consumers not= ice >> that they may have to update their tools or switch to a different >> processing function >> >> Given that vmstate annotations will most probably require some work on= >> the output structure (and I don't have a QMP use case ATM anyway), I >> would be fine with the first option for now. Still, I don't think we >> will ever get beyond the second option because this service is tight t= o >> some internals of QEMU we don't want to freeze. >> =20 >=20 > I agree. This feature is very useful as a debugging aid, and as I don'= t > think we'll have debugging GUIs any time soon, it's better to defer the= > problem until we really need to solve it. I introduced .user_only as a monitor command tag and applied it on device_show. But I also added the vmstate version to the device output, maybe already helpful for users. All this will come with v3. Jan --------------enigDE78E24CE6DD25E05236EEAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkv4/YYACgkQitSsb3rl5xTA1gCcDHC998u3dfp90vhNiLKIki6Q 4I0AoLWObK8OhtgO772dAEJL2zI9UXgN =tgqh -----END PGP SIGNATURE----- --------------enigDE78E24CE6DD25E05236EEAB--