Hi, I work on NVDIMM support in oVirt/RHV, I think other virtualization management software built on top of QEMU may have similar concerns.
When a virtual NVDIMM device size is specified, it's not necessarily the eventual NVDIMM device size visible to the guest OS. As seen in https://github.com/qemu/qemu/blob/v6.0.0/hw/mem/nvdimm.c#L117, QEMU makes some adjustments (other adjustments are performed by libvirt but that's a topic for a different forum): - NVDIMM label size is subtracted from the NVDIMM size. - NVDIMM label is pointed to a certain memory region. - The remaining NVDIMM size is aligned down. There are some related potential problems: - If the alignment rules change in a future QEMU version, it may result in a different device size visible to the guest (even if the requested size remains the same) and cause trouble there up to data loss. - If the layout on the backing device changes, e.g. a label placement, then the stored data may become corrupt or inaccessible. - I'm not sure about the current QEMU version, but at least in previous QEMU versions, the resulting size is important for memory hot plug. The NVDIMM alignment size is smaller than the required regular memory DIMM placement alignment. If a VM contains an NVDIMM with the resulting size not matching the DIMM placement requirements and a memory hot plug is attempted then the hot plug fails because the DIMM is mapped next to the end of the NVDIMM region, which is not DIMM-aligned. All this means: - The requested NVDIMM size must be computed and specified carefully, with attention to QEMU internal implementation. - And because it depends on QEMU internal implementation, there is a risk of malfunction or data loss when the same backing device with the same parameters is used with a future QEMU version. As for labels, I was told NVDIMM labels might be put to regular files in future to avoid some problems. Since label placement is not visible to the guest, such a change could be made transparently without disrupting access to the data. (As long as the label data is transferred to the new location properly and undesirable resulting NVDIMM size changes are not induced by such a change.) The primary point is still how to ensure that data kept on a backing device will remain accessible and safe in future QEMU versions and how to possibly avoid reliance on QEMU implementation details. A big warning in the NVDIMM handling source code to keep backward compatibility (incl. memory hot plugs) and data safety on mind before making any changes there might be a reasonable minimum measure. Any additional ideas? What do you think about it all? Thank you, Milan
