On 03/07/2018 08:33 PM, Haozhong Zhang wrote:
It may need to treat PC-DIMM and NVDIMM differently, e.g., when
deciding the necessity of non-volatile flag bit in SRAT memory
affinity structures.
NVDIMMDeviceInfo, which inherits from PCDIMMDeviceInfo, is added to
union type MemoryDeviceInfo to record information of NVDIMM devices.
The NVDIMM-specific data is currently left empty and will be filled
when necessary in the future.
It also fixes "info memory-devices"/query-memory-devices which
currently show nvdimm devices as dimm devices since
object_dynamic_cast(obj, TYPE_PC_DIMM) happily cast nvdimm to
TYPE_PC_DIMM which it's been inherited from.
Signed-off-by: Haozhong Zhang <haozhong.zh...@intel.com>
---
+++ b/qapi/misc.json
@@ -2830,6 +2830,18 @@
}
}
+##
+# @NVDIMMDeviceInfo:
+#
+# NVDIMMDevice state information
+#
+# Since: 2.12
+##
+{ 'struct': 'NVDIMMDeviceInfo',
+ 'base': 'PCDIMMDeviceInfo',
+ 'data': {}
+}
+
As long as you don't have any data members to add, you could omit this
type...
##
# @MemoryDeviceInfo:
#
@@ -2837,7 +2849,11 @@
#
# Since: 2.1
##
-{ 'union': 'MemoryDeviceInfo', 'data': {'dimm': 'PCDIMMDeviceInfo'} }
+{ 'union': 'MemoryDeviceInfo',
+ 'data': { 'dimm': 'PCDIMMDeviceInfo',
+ 'nvdimm': 'NVDIMMDeviceInfo'
+ }
and just write this as
'data': { 'dimm': 'PCDIMMDeviceInfo',
'nvdimm': 'PCDIMMDeviceInfo' }
If, down the road, you want to add data members to one but not both of
the branches, we can add a new (sub-)type at that time, and it won't
break backwards compatibility.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
