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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171027211248.GL2566>