From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKCFG-00071V-NK for qemu-devel@nongnu.org; Wed, 20 Aug 2014 16:12:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKCFC-0003bV-7m for qemu-devel@nongnu.org; Wed, 20 Aug 2014 16:12:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKCFC-0003ZJ-18 for qemu-devel@nongnu.org; Wed, 20 Aug 2014 16:12:30 -0400 Message-ID: <53F50128.1030400@redhat.com> Date: Wed, 20 Aug 2014 14:12:24 -0600 From: Eric Blake MIME-Version: 1.0 References: <1408556804-5266-1-git-send-email-marc.mari.barcelo@gmail.com> <53F4F260.8030600@redhat.com> In-Reply-To: <53F4F260.8030600@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NJlUMKta63FPkM1v1QdQdmNefP7hkmsHn" Subject: Re: [Qemu-devel] [RFC] qapi: New command query-mtree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?TWFyYyBNYXLDrQ==?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Stefan Hajnoczi , Peter Maydell This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NJlUMKta63FPkM1v1QdQdmNefP7hkmsHn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/20/2014 01:09 PM, Eric Blake wrote: > On 08/20/2014 11:46 AM, Marc Mar=C3=AD wrote: >> Add command query-mtree to get the memory tree of the guest. >> >> As we were looking for a flexible solution on accessing the guest memo= ry from >> qtests, Stefan came with the idea to implement this new qmp command. >> >> This way, the result can be parsed, and the RAM direction extracted, s= o only >> a generic qtest malloc is necessary and not one per machine, as it is >> implemented at the moment (malloc-pc uses fw_cfg). >> >> The actual output is this: http://pastebin.com/nHAH9Jie >> Which corresponds to this info mtree: http://pastebin.com/B5vw8DDf >=20 >=20 >> +## >> +{ 'command': 'query-mtree', 'returns': 'MemTree' } >=20 > I was expecting ['MemTree'] (an array of structs), but you gave > 'MemTreee' (a struct of parallel arrays). Am I guaranteed that > returns.spaces and returns.aliases are arrays of the same length? If > not, what's the difference between 'spaces' and 'aliases' (that is, why= > do I need two arrays)? Should the designation of 'space' vs. 'alias' b= e > part of the 'AddrSpace' struct, rather than having to be learned > indirectly by which of the two arrays it appeared in? >=20 Looking at your pastebin, I'm seeing some repetition. For example: return.spaces[0].mem.submr[0] is (line 11 in the pastebin): { u'name': u'ram-below-4g', u'prio': 0, u'read': True, u'ram': False, u'write': True, u'alias': u'pc.ram', u'base': 0, u'size': 536870911 }, Later, return.aliases[0] is (line 858): u'mem': { u'name': u'pc.ram', u'prio': 0, u'read': True, u'ram': True, u'write': True, u'base': 0, u'size': 536870911 }, u'name': u'pc.ram' Isn't that two descriptions of the same region? Would it be better if one of the references in the JSON was just a name, and make the caller look up that name in the other location, instead of inlining the full struct at both locations? On the other hand, the 'ram' field for that memory region appears to be different depending on whether you access it via the subregion of system vs. via the pc.ram alias. Okay, maybe that much complexity really is necessary. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --NJlUMKta63FPkM1v1QdQdmNefP7hkmsHn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT9QEoAAoJEKeha0olJ0Nqn7EH/A83bfZDFvDKnuQcvzROJv/i 6sXRw8DRVPez7NHxwoz8H2ZvegaF7Dlq1OCMPpUccveqpsntMX7Ith1wp2PWhs8r eoEiUTj8Wnb1RiaHUreznD/AzvAtkFlc3eWodTblyKvpspi+iLFznx/Vo1AP/Qsc z+9qFp9y796a9a8hQ0Q633QnUKxZoxDjuAoRzSQ/RtB3cX8U9K3tPt2WOItcbxx8 z2VHdUfxHX4c55bSm4T0RUIo57610HHL80meTG4C6oNEuAhsUrtW2DauZMKpllZ3 x7F45LizgkrqrCjzGX5SM/8Z2VOsnbhmkCR3g+3XLVwAdypwaR0Vc1e7WWMKqiw= =EO5j -----END PGP SIGNATURE----- --NJlUMKta63FPkM1v1QdQdmNefP7hkmsHn--