Adjustments of NVDIMM devices and future data safety

[Milan Zamazal]

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