Re: [PATCH v2 20/20] libnd, nd_acpi, nd_blk: driver for BLK-mode access persistent memory

From: Dan Williams
Date: Wed Apr 29 2015 - 13:10:42 EST


On Tue, Apr 28, 2015 at 4:06 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Tue, Apr 28, 2015 at 3:30 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>> On Tue, Apr 28, 2015 at 2:10 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> On Tue, Apr 28, 2015 at 11:26 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>>>> From: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
>>>>
>>>> The libnd implementation handles allocating dimm address space (DPA)
>>>> between PMEM and BLK mode interfaces. After DPA has been allocated from
>>>> a BLK-region to a BLK-namespace the nd_blk driver attaches to handle I/O
>>>> as a struct bio based block device. Unlike PMEM, BLK is required to
>>>> handle platform specific details like mmio register formats and memory
>>>> controller interleave. For this reason the libnd generic nd_blk driver
>>>> calls back into the bus provider to carry out the I/O.
>>>>
>>>> This initial implementation handles the BLK interface defined by the
>>>> ACPI 6 NFIT [1] and the NVDIMM DSM Interface Example [2] composed from
>>>> DCR (dimm control region), BDW (block data window), IDT (interleave
>>>> descriptor) NFIT structures and the hardware register format.
>>>> [1]: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
>>>> [2]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>>>>
>>>> Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
>>>> Cc: Boaz Harrosh <boaz@xxxxxxxxxxxxx>
>>>> Cc: H. Peter Anvin <hpa@xxxxxxxxx>
>>>> Cc: Jens Axboe <axboe@xxxxxx>
>>>> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
>>>> Cc: Christoph Hellwig <hch@xxxxxx>
>>>> Signed-off-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
>>>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
>>>> ---
>>>> drivers/block/nd/Kconfig | 12 +
>>>> drivers/block/nd/Makefile | 3
>>>> drivers/block/nd/acpi.c | 422 +++++++++++++++++++++++++++++++++++--
>>>> drivers/block/nd/acpi_nfit.h | 47 ++++
>>>> drivers/block/nd/blk.c | 264 +++++++++++++++++++++++
>>>> drivers/block/nd/libnd.h | 11 +
>>>> drivers/block/nd/namespace_devs.c | 47 ++++
>>>> drivers/block/nd/nd-private.h | 3
>>>> drivers/block/nd/nd.h | 16 +
>>>> drivers/block/nd/region.c | 8 +
>>>> drivers/block/nd/region_devs.c | 65 +++++-
>>>> drivers/block/nd/test/nfit.c | 29 +++
>>>> drivers/block/nd/test/nfit_test.h | 2
>>>> 13 files changed, 891 insertions(+), 38 deletions(-)
>>>> create mode 100644 drivers/block/nd/blk.c
>>>>
>>>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>>>> index 612bf2b14283..bac4290129fc 100644
>>>> --- a/drivers/block/nd/Kconfig
>>>> +++ b/drivers/block/nd/Kconfig
>>>> @@ -95,6 +95,18 @@ config BLK_DEV_PMEM
>>>>
>>>> Say Y if you want to use a NVDIMM described by ACPI, E820, etc...
>>>>
>>>> +config ND_BLK
>>>> + tristate "BLK: Block data window (aperture) device support"
>>>> + depends on LIBND
>>>> + default ND_ACPI
>>>> + help
>>>> + This driver performs I/O using a set of mmio windows on a
>>>> + dimm. The set of apertures will all access the one DIMM.
>>>> + Multiple windows allow multiple threads to have a different
>>>> + portions of the dimm open at one time.
>>>> +
>>>> + Say Y if you want to use a NVDIMM with BLK-mode capability
>>>> +
>>>
>>> This describes how it works, not what it is. How about:
>>>
>>> This driver exposes NVDIMM BLK regions as block devices. BLK regions
>>> are regions of NVDIMM storage that are sector-addressable, not
>>> byte-addressible, and do not support DAX.
>>
>> They *are* byte-addressable albeit through an indirection window. The
>> indirection windows are too small for DAX to be a viable access mode.
>
> Right, I was assuming incorrectly that the sector-atomic thing was a
> necessary part of BLK, or at least of this implementation.
>
> Anyway, I think my point stands: let's describe what these drivers do
> from a user's perspective, not how they work.

Agreed. How about:

"Support NVDIMMs, or other devices, that implement a BLK-mode access
capability. BLK-mode access uses memory-mapped-i/o apertures to
access persistent media.

Say Y if your platform firmware emits an ACPI.NFIT table
(CONFIG_ND_ACPI), or otherwise exposes BLK-mode capabilities."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/