[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdi
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
On 10/11/2016 03:22 AM, Markus Armbruster wrote:
> query-memory-devices returns a list of MemoryDeviceInfo:
>
> ##
> # @MemoryDeviceInfo:
> #
> # Union containing information about a memory device
> #
> # Since: 2.1
> ##
> { 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
>
> This is a union, designed to be extended for other types of memory
> device frontends.
>
> Sadly, it's a "simple" union (I dislike those).
>
> You could add a new member to be used for the NVDIMM case. It would
> probably duplicate some or all of PCDIMMDeviceInfo, though.
>
> If it needs all of PCDIMMDeviceInfo, you could make the new member's
> type have PCDIMMDeviceInfo as base.
>
> 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [RFC QEMU PATCH 3/8] nvdimm acpi: do not use fw_cfg on Xen, (continued)
- [Qemu-devel] [RFC QEMU PATCH 3/8] nvdimm acpi: do not use fw_cfg on Xen, Haozhong Zhang, 2016/10/09
- [Qemu-devel] [RFC QEMU PATCH 4/8] nvdimm acpi: build and copy NFIT to guest on Xen, Haozhong Zhang, 2016/10/09
- [Qemu-devel] [RFC QEMU PATCH 5/8] nvdimm acpi: build and copy NVDIMM namespace devices to guest on Xen, Haozhong Zhang, 2016/10/09
- [Qemu-devel] [RFC QEMU PATCH 6/8] hostmem: add a host memory backend for Xen, Haozhong Zhang, 2016/10/09
- [Qemu-devel] [RFC QEMU PATCH 7/8] xen-hvm: create hotplug memory region for HVM guest, Haozhong Zhang, 2016/10/09
- [Qemu-devel] [RFC QEMU PATCH 8/8] qmp: add a qmp command 'query-nvdimms' to get plugged NVDIMM devices, Haozhong Zhang, 2016/10/09
Re: [Qemu-devel] [RFC QEMU PATCH 0/8] Implement vNVDIMM for Xen HVM guest, no-reply, 2016/10/10