Date: Fri, 27 Oct 2017 14:56:47 -0600 From: Rebecca Cran <rebecca@bluestop.org> To: freebsd-arch@freebsd.org Cc: Ravi Pokala <rpokala@mac.com> Subject: Re NVDIMM status report (2017-03-25) Message-ID: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org>
next in thread | raw e-mail | index | archive | help
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. -- Rebecca Cran [0] https://msdn.microsoft.com/en-us/library/windows/hardware/mt604741(v=vs.85).aspx [1] http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a504eb3-0194-850a-4f36-345b7a2a738e>