Re NVDIMM status report (2017-03-25)

[Rebecca Cran]

I'm replying to the original message at
https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018165.html
(sorry, I'm not sure how to get the raw email to import and reply to
properly).


"Traditional" NVDIMMs have been standardized under JEDEC with the name
'NVDIMM-N': NVDIMM-P is an upcoming specification that will be for
'persistent'  or 'storage class' memory modules such as 3D X-Point.
NVDIMM-F is another standard, that puts NAND directly on the memory bus
and allows accesses directly. It's very slow, and only allows block
accesses. NVDIMM-P should be in-between NVDIMM-N and NVDIMM-F in terms
of speed/latency.


In terms of proprietary interfaces, there are at least 3 ACPI DSMs: HPE,
Microsoft[0] and Intel[1]. The ACPI Working Group has started to work on
bringing them together under a single specification, but it's still
early days. JEDEC has however published the BAEBI (Byte Addressable
Energy Backed Interface) that's the basis for the DSM, and runs over
I2C. OEMs often lock down access to the I2C bus on boot however,
requiring all accesses to be via ACPI.

There's currently no widespread support in UEFI for NVDIMMs: I have
prototype code running which allows OVMF running under Qemu to enumerate
them and populate the "Persistent Memory" entry of the 'memmap' shell
command, but that's as far as it goes so far.

[Konstantin Belousov]

Post by Rebecca Cran
I'm replying to the original message at
https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018165.html
(sorry, I'm not sure how to get the raw email to import and reply to
properly).
"Traditional" NVDIMMs have been standardized under JEDEC with the name
'NVDIMM-N': NVDIMM-P is an upcoming specification that will be for
'persistent'  or 'storage class' memory modules such as 3D X-Point.
NVDIMM-F is another standard, that puts NAND directly on the memory bus
and allows accesses directly. It's very slow, and only allows block
accesses. NVDIMM-P should be in-between NVDIMM-N and NVDIMM-F in terms
of speed/latency.
In terms of proprietary interfaces, there are at least 3 ACPI DSMs: HPE,
Microsoft[0] and Intel[1]. The ACPI Working Group has started to work on
bringing them together under a single specification, but it's still
early days. JEDEC has however published the BAEBI (Byte Addressable
Energy Backed Interface) that's the basis for the DSM, and runs over
I2C. OEMs often lock down access to the I2C bus on boot however,
requiring all accesses to be via ACPI.
There's currently no widespread support in UEFI for NVDIMMs: I have
prototype code running which allows OVMF running under Qemu to enumerate
them and populate the "Persistent Memory" entry of the 'memmap' shell
command, but that's as far as it goes so far.

Perhaps I have some more code. It is more of 'me too' response than
something that can be used practically.

My WIP patch is at https://kib.kiev.ua/kib/nvdimm.1.patch .

Half of it is the KPI to map very large physical memory ranges into
KVA, another half is the germ of the driver. The driver provides two
devices: one is /dev/nvdimm_spaX for each SPA region, which allows io
and zero-copy userspace mapping. Another device is /dev/spaX which is in
fact geom and it can be mounted after formatting in UFS.

Namespaces support is missed, but planned, same for the blocks access
interface.