Comment 7 for bug 1853506

On 26/11/2019 04:01, Christian Ehrhardt  wrote:
> @Rafael - Seths comment is correct but I think can be alleviated with instructions how to do that on virtual HW. I know you have testing info on bug 1811785 and that you are working on more aspects of it, so maybe you have even better/extended instructions now.
> I'd ask you to)
> a) add a comment here how this can be tested via qemu emulating pmem
Yes, looks like NVDIMM emulation in QEMU
(https://github.com/qemu/qemu/blob/master/docs/nvdimm.txt) is in good
shape. The direct pass-through gives us no VM_EXITs and direct access to
the host files AND we can use, as I did, the NVDIMM emulation *from* a
host file.

We usually have:

PMEM: the physical addresses that are mapped to one or more nvdimms
(writes are persistent).
DAX: a block device composed of PMEM is DAX capable (fs extension to
bypass cache and block layer)
BW (block window): set of registers (command, status, aperture) to
read/write blocks in any part of NVDIMM
BLK: memory mapped I/O
BTT (block translation table): like a journal data structure defined in
nvdimm namespace specs.
Namespace: Similar to a partition or LUN (or a NVMe namespace)
NFIT (NVDIMM Firmware Interface Table): ACPI table to inform OS about
NVDIMMs
DSM (Device Specific Method): specific methods for particular NVDIMM
implementation.

The QEMU does NOT implement the BW (Block Window Mode). So we would rely
only on the MMIO-like capabilities of the virtual NVDIMM only: Accessing
NVDIMM through NVM libraries AND through the regular VFS <-> Dax Enabled
Filesystem interface (ext4, xfs). I think it is enough for enablement.

> b) If confirmed below by Seth, add a test script to qa-regression-tools based on (a)
IMO, basic DEP8 should include:

1) Add test for configuring regions & namespaces
2) Add test for testing a DAX enabled filesystem
3) Add test to test accessing NVDIMMs through NVM libs

> @Seth - I think this could be mostly done virtualized.
> Would security be ok if we outline how it works, maybe even add a test to the qa-regression-test report for it?
> For real HW it will depend on the manufacturer and even if we'd buy one we wouldn't have all the other variants - as with other special HW (think of the 1001+ different network cards out there) once debugging reaches the assumption that it is HW dependent we will have to ping and wait for the manufacturer.
If we concentrate in the virtual NVDIMMs for enablement, we can use the
public bugs to guarantee better compatibility. Just like we do for
multipath-tools, for example. We usually don't test ALL existing HBAs
and/or iSCSI storage-servers, but we guarantee the multipath-tools core
is good and fix issues as they appear (discovering ALUA issues w/ weird
storage-servers here and there). Just one example that came to my mind.