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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1853506 Title: [MIR] ndctl To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
