From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyJe-0004xk-PG for qemu-devel@nongnu.org; Tue, 11 Oct 2016 10:46:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btyJc-0008Ej-CZ for qemu-devel@nongnu.org; Tue, 11 Oct 2016 10:46:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyJc-0008ET-2y for qemu-devel@nongnu.org; Tue, 11 Oct 2016 10:46:00 -0400 References: <20161010003423.4333-1-haozhong.zhang@intel.com> <20161010003423.4333-9-haozhong.zhang@intel.com> <091ebe9c-70d3-e352-dbc3-8bd05905fa77@redhat.com> <20161011063114.gh5ii35mhi32h3w6@hz-desktop> <87d1j7pa62.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: Date: Tue, 11 Oct 2016 09:45:56 -0500 MIME-Version: 1.0 In-Reply-To: <87d1j7pa62.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v" Subject: Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Xiao Guangrong , Konrad Rzeszutek Wilk , "Michael S. Tsirkin" , Igor Mammedov This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v From: Eric Blake To: Markus Armbruster Cc: qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Xiao Guangrong , Konrad Rzeszutek Wilk , "Michael S. Tsirkin" , Igor Mammedov Message-ID: Subject: Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices References: <20161010003423.4333-1-haozhong.zhang@intel.com> <20161010003423.4333-9-haozhong.zhang@intel.com> <091ebe9c-70d3-e352-dbc3-8bd05905fa77@redhat.com> <20161011063114.gh5ii35mhi32h3w6@hz-desktop> <87d1j7pa62.fsf@dusky.pond.sub.org> In-Reply-To: <87d1j7pa62.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/11/2016 03:22 AM, Markus Armbruster wrote: > query-memory-devices returns a list of MemoryDeviceInfo: >=20 > ## > # @MemoryDeviceInfo: > # > # Union containing information about a memory device > # > # Since: 2.1 > ## > { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'}= } >=20 > This is a union, designed to be extended for other types of memory > device frontends. >=20 > Sadly, it's a "simple" union (I dislike those). >=20 > You could add a new member to be used for the NVDIMM case. It would > probably duplicate some or all of PCDIMMDeviceInfo, though. >=20 > If it needs all of PCDIMMDeviceInfo, you could make the new member's > type have PCDIMMDeviceInfo as base. >=20 > If we can identify information *any* memory device frontend should have= , > the appropriate design would be a flat union with common information > common, and type-specific information in union branches. Could > MemoryDeviceInfo be backward-compatibly morphed into such a type? Yes, conversion to a flat union is possible without breaking existing QMP usage. It would look something like this (with anonymous base and branch classes, which is still one of my pending qapi patches to post): { 'enum': 'MemoryDeviceType', 'data': [ 'dimm', 'nvdimm' ] } { 'union': 'MemoryDeviceInfo', 'base': { 'type': 'MemoryDeviceType' }, 'discriminator': 'type', 'data': { 'dimm': { 'data': 'PCIMMDeviceInfo' }, 'nvdimm': 'whatever_type_here' } } We would still have back-compatible: { "type": "dimm", "data": { "addr":..., "size":..., ... } } for dimm, and for nvdimm, we would have { "type": "nvdimm", whatever fields we want here } whether we want all the fields to be flattened in the nvdimm case, vs. nested (for back-compat) under a 'data' dict in the 'dimm' case, or whether we want both uses to be nested under a 'data' dict for consistency, is a matter of taste. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJX/PskAAoJEKeha0olJ0NqescH/2qnI8KOIFB5oRvuLuVjOXiW LjVa3T/+1dbKKxR7gt1wqeWL1rT06wn7UExKUdCbQXN6gieBw8oUsmM0uvMJifiK MnvskdD1QEZZEXcIvcAfE2JK43AHVTNPHFY+GMXnfKtNGME11pZ7VsVM25ptG05b cEcWpybjWsRevVWPowpa11fp91AFTzpjPsjafGfwDfkDBcRejZRhEPGyUveBX1nw zHAGlV8M7SJUu96kE/Sp7tPkR2/nGM6s6y97FCwXAPYGOgY1AM/UUknVXH2FwV46 JTn+UcVtFcxVBkKJHbZm0g7v/2OfO6Q7Th8zw3Kb/ikqh41q8wEKMicWmdwuRNM= =4hdq -----END PGP SIGNATURE----- --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Blake Subject: Re: [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices Date: Tue, 11 Oct 2016 09:45:56 -0500 Message-ID: References: <20161010003423.4333-1-haozhong.zhang@intel.com> <20161010003423.4333-9-haozhong.zhang@intel.com> <091ebe9c-70d3-e352-dbc3-8bd05905fa77@redhat.com> <20161011063114.gh5ii35mhi32h3w6@hz-desktop> <87d1j7pa62.fsf@dusky.pond.sub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v" Return-path: In-Reply-To: <87d1j7pa62.fsf@dusky.pond.sub.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" To: Markus Armbruster Cc: xen-devel@lists.xensource.com, Xiao Guangrong , "Michael S. Tsirkin" , Konrad Rzeszutek Wilk , qemu-devel@nongnu.org, Igor Mammedov List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v From: Eric Blake To: Markus Armbruster Cc: qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Xiao Guangrong , Konrad Rzeszutek Wilk , "Michael S. Tsirkin" , Igor Mammedov Message-ID: Subject: Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices References: <20161010003423.4333-1-haozhong.zhang@intel.com> <20161010003423.4333-9-haozhong.zhang@intel.com> <091ebe9c-70d3-e352-dbc3-8bd05905fa77@redhat.com> <20161011063114.gh5ii35mhi32h3w6@hz-desktop> <87d1j7pa62.fsf@dusky.pond.sub.org> In-Reply-To: <87d1j7pa62.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/11/2016 03:22 AM, Markus Armbruster wrote: > query-memory-devices returns a list of MemoryDeviceInfo: >=20 > ## > # @MemoryDeviceInfo: > # > # Union containing information about a memory device > # > # Since: 2.1 > ## > { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'}= } >=20 > This is a union, designed to be extended for other types of memory > device frontends. >=20 > Sadly, it's a "simple" union (I dislike those). >=20 > You could add a new member to be used for the NVDIMM case. It would > probably duplicate some or all of PCDIMMDeviceInfo, though. >=20 > If it needs all of PCDIMMDeviceInfo, you could make the new member's > type have PCDIMMDeviceInfo as base. >=20 > If we can identify information *any* memory device frontend should have= , > the appropriate design would be a flat union with common information > common, and type-specific information in union branches. Could > MemoryDeviceInfo be backward-compatibly morphed into such a type? Yes, conversion to a flat union is possible without breaking existing QMP usage. It would look something like this (with anonymous base and branch classes, which is still one of my pending qapi patches to post): { 'enum': 'MemoryDeviceType', 'data': [ 'dimm', 'nvdimm' ] } { 'union': 'MemoryDeviceInfo', 'base': { 'type': 'MemoryDeviceType' }, 'discriminator': 'type', 'data': { 'dimm': { 'data': 'PCIMMDeviceInfo' }, 'nvdimm': 'whatever_type_here' } } We would still have back-compatible: { "type": "dimm", "data": { "addr":..., "size":..., ... } } for dimm, and for nvdimm, we would have { "type": "nvdimm", whatever fields we want here } whether we want all the fields to be flattened in the nvdimm case, vs. nested (for back-compat) under a 'data' dict in the 'dimm' case, or whether we want both uses to be nested under a 'data' dict for consistency, is a matter of taste. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJX/PskAAoJEKeha0olJ0NqescH/2qnI8KOIFB5oRvuLuVjOXiW LjVa3T/+1dbKKxR7gt1wqeWL1rT06wn7UExKUdCbQXN6gieBw8oUsmM0uvMJifiK MnvskdD1QEZZEXcIvcAfE2JK43AHVTNPHFY+GMXnfKtNGME11pZ7VsVM25ptG05b cEcWpybjWsRevVWPowpa11fp91AFTzpjPsjafGfwDfkDBcRejZRhEPGyUveBX1nw zHAGlV8M7SJUu96kE/Sp7tPkR2/nGM6s6y97FCwXAPYGOgY1AM/UUknVXH2FwV46 JTn+UcVtFcxVBkKJHbZm0g7v/2OfO6Q7Th8zw3Kb/ikqh41q8wEKMicWmdwuRNM= =4hdq -----END PGP SIGNATURE----- --ilhMWvbpQQ8IHA3DIs9rhP0nIxw605G0v--