Date: Sat, 28 Oct 2017 00:12:48 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Rebecca Cran <rebecca@bluestop.org> Cc: freebsd-arch@freebsd.org, Ravi Pokala <rpokala@mac.com> Subject: Re: Re NVDIMM status report (2017-03-25) Message-ID: <20171027211248.GL2566@kib.kiev.ua> In-Reply-To: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org> References: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 27, 2017 at 02:56:47PM -0600, Rebecca Cran wrote: > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171027211248.GL2566>