07 Nov, 2019

1 commit

  • In preparation for handling platform differentiated memory types beyond
    persistent memory, uplevel the "region" identifier to a global number
    space. This enables a device-dax instance to be registered to any memory
    type with guaranteed unique names.

    Signed-off-by: Dan Williams
    Acked-by: Thomas Gleixner
    Signed-off-by: Rafael J. Wysocki

    Dan Williams
     

07 Sep, 2019

1 commit

  • The infrastructure to mock core libnvdimm routines for unit testing
    purposes is prone to bitrot relative to refactoring of that core. Arrange
    for the unit test core to be built when CONFIG_COMPILE_TEST=y. This does
    not result in a functional unit test environment, it is only a helper for
    0day to catch unit test build regressions.

    Note that there are a few x86isms in the implementation, so this does not
    bother compile testing this architectures other than 64-bit x86.

    Link: https://lore.kernel.org/r/156763690875.2556198.15786177395425033830.stgit@dwillia2-desk3.amr.corp.intel.com
    Reported-by: Christoph Hellwig
    Signed-off-by: Dan Williams
    Signed-off-by: Jason Gunthorpe

    Dan Williams
     

15 Jul, 2019

2 commits


21 May, 2019

1 commit


14 Dec, 2018

1 commit

  • Add support to unlock the dimm via the kernel key management APIs. The
    passphrase is expected to be pulled from userspace through keyutils.
    The key management and sysfs attributes are libnvdimm generic.

    Encrypted keys are used to protect the nvdimm passphrase at rest. The
    master key can be a trusted-key sealed in a TPM, preferred, or an
    encrypted-key, more flexible, but more exposure to a potential attacker.

    Signed-off-by: Dave Jiang
    Co-developed-by: Dan Williams
    Reported-by: Randy Dunlap
    Signed-off-by: Dan Williams

    Dave Jiang
     

20 Apr, 2018

1 commit


10 Apr, 2018

2 commits


07 Apr, 2018

1 commit

  • This patch adds peliminary device-tree bindings for persistent memory
    regions. The driver registers a libnvdimm bus for each pmem-region
    node and each address range under the node is converted to a region
    within that bus.

    Signed-off-by: Oliver O'Halloran
    Signed-off-by: Dan Williams

    Oliver O'Halloran
     

03 Apr, 2018

1 commit

  • In support of allowing device-mapper to compile out idle/dead code when
    there are no dax providers in the system, introduce the DAX_DRIVER
    symbol. This is selected by all leaf drivers that device-mapper might be
    layered on top. This allows device-mapper to conditionally 'select DAX'
    only when a provider is present.

    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Reported-by: Bart Van Assche
    Reviewed-by: Mike Snitzer
    Signed-off-by: Dan Williams

    Dan Williams
     

12 Oct, 2017

1 commit


20 Apr, 2017

1 commit

  • Setup a dax_device to have the same lifetime as the pmem block device
    and add a ->direct_access() method that is equivalent to
    pmem_direct_access(). Once fs/dax.c has been converted to use
    dax_operations the old pmem_direct_access() will be removed.

    Signed-off-by: Dan Williams

    Dan Williams
     

19 Nov, 2016

1 commit


28 Oct, 2016

1 commit

  • A bugfix just tried to address a randconfig build problem and introduced
    a variant of the same problem: with CONFIG_LIBNVDIMM=y and
    CONFIG_NVDIMM_DAX=m, the nvdimm module now fails to link:

    drivers/nvdimm/built-in.o: In function `to_nd_device_type':
    bus.c:(.text+0x1b5d): undefined reference to `is_nd_dax'
    drivers/nvdimm/built-in.o: In function `nd_region_notify_driver_action.constprop.2':
    region_devs.c:(.text+0x6b6c): undefined reference to `is_nd_dax'
    region_devs.c:(.text+0x6b8c): undefined reference to `to_nd_dax'
    drivers/nvdimm/built-in.o: In function `nd_region_probe':
    region.c:(.text+0x70f3): undefined reference to `nd_dax_create'
    drivers/nvdimm/built-in.o: In function `mode_show':
    namespace_devs.c:(.text+0xa196): undefined reference to `is_nd_dax'
    drivers/nvdimm/built-in.o: In function `nvdimm_namespace_common_probe':
    (.text+0xa55f): undefined reference to `is_nd_dax'
    drivers/nvdimm/built-in.o: In function `nvdimm_namespace_common_probe':
    (.text+0xa56e): undefined reference to `to_nd_dax'

    This reverts the earlier fix, making NVDIMM_DAX a 'bool' option again
    as it should be (it gets linked into the libnvdimm module). To fix
    the original problem, I'm adding a dependency on LIBNVDIMM to
    DEV_DAX_PMEM, which ensures we can't have that one built-in if the
    rest is a module.

    Fixes: 4e65e9381c7a ("/dev/dax: fix Kconfig dependency build breakage")
    Signed-off-by: Arnd Bergmann
    Reviewed-by: Ross Zwisler
    Signed-off-by: Dan Williams

    Arnd Bergmann
     

24 Oct, 2016

1 commit


08 Oct, 2016

1 commit

  • The function dax_pmem_probe() in drivers/dax/pmem.c is compiled under the
    CONFIG_DEV_DAX_PMEM tri-state config option. This config option currently
    only depends on CONFIG_NVDIMM_DAX, a bool, which means that the following
    configuration is possible:

    CONFIG_LIBNVDIMM=m
    ...
    CONFIG_NVDIMM_DAX=y
    CONFIG_DEV_DAX=y
    CONFIG_DEV_DAX_PMEM=y

    With this config LIBNVDIMM is compiled as a module with NVDIMM_DAX=y just
    meaning that we will compile drivers/nvdimm/dax_devs.c into that module.
    However, dax_pmem_probe() depends on several symbols defined in
    drivers/nvdimm/dax_devs.c, which results in the following build errors:

    drivers/built-in.o: In function `dax_pmem_probe':
    linux/drivers/dax/pmem.c:70: undefined reference to `to_nd_dax'
    linux/drivers/dax/pmem.c:74: undefined reference to
    `nvdimm_namespace_common_probe'
    linux/drivers/dax/pmem.c:80: undefined reference to `devm_nsio_enable'
    linux/drivers/dax/pmem.c:81: undefined reference to `nvdimm_setup_pfn'
    linux/drivers/dax/pmem.c:84: undefined reference to `devm_nsio_disable'
    linux/drivers/dax/pmem.c:122: undefined reference to `to_nd_region'
    drivers/built-in.o: In function `dax_pmem_init':
    linux/drivers/dax/pmem.c:147: undefined reference to `__nd_driver_register'

    Fix this by making NVDIMM_DAX a tristate. DEV_DAX_PMEM depends on
    NVDIMM_DAX which depends on LIBNVDIMM. Since they are all now tristates,
    if LIBNVDIMM is built as a kernel module DEV_DAX_PMEM will be as well.
    This prevents dax_devs.c from being built as a built-in while its
    dependencies are in the libnvdimm.ko module.

    Signed-off-by: Ross Zwisler
    Signed-off-by: Dan Williams

    Ross Zwisler
     

08 Jul, 2016

1 commit

  • In preparation for generically mapping flush hint addresses for both the
    BLK and PMEM use case, provide a generic / reference counted mapping
    api. Given the fact that a dimm may belong to multiple regions (PMEM
    and BLK), the flush hint addresses need to be held valid as long as any
    region associated with the dimm is active. This is similar to the
    existing BLK-region case where multiple BLK-regions may share an
    aperture mapping. Up-level this shared / reference-counted mapping
    capability from the nfit driver to a core nvdimm capability.

    This eliminates the need for the nd_blk_region.disable() callback. Note
    that the removal of nfit_spa_map() and related infrastructure is
    deferred to a later patch.

    Signed-off-by: Dan Williams

    Dan Williams
     

10 May, 2016

1 commit

  • Device DAX is the device-centric analogue of Filesystem DAX
    (CONFIG_FS_DAX). It allows persistent memory ranges to be allocated and
    mapped without need of an intervening file system. This initial
    infrastructure arranges for a libnvdimm pfn-device to be represented as
    a different device-type so that it can be attached to a driver other
    than the pmem driver.

    Signed-off-by: Dan Williams

    Dan Williams
     

29 Aug, 2015

2 commits

  • Enable the pmem driver to handle PFN device instances. Attaching a pmem
    namespace to a pfn device triggers the driver to allocate and initialize
    struct page entries for pmem. Memory capacity for this allocation comes
    exclusively from RAM for now which is suitable for low PMEM to RAM
    ratios. This mechanism will be expanded later for setting an "allocate
    from PMEM" policy.

    Cc: Boaz Harrosh
    Cc: Ross Zwisler
    Cc: Christoph Hellwig
    Signed-off-by: Dan Williams

    Dan Williams
     
  • Implement the base infrastructure for libnvdimm PFN devices. Similar to
    BTT devices they take a namespace as a backing device and layer
    functionality on top. In this case the functionality is reserving space
    for an array of 'struct page' entries to be handed out through
    pfn_to_page(). For now this is just the basic libnvdimm-device-model for
    configuring the base PFN device.

    As the namespace claiming mechanism for PFN devices is mostly identical
    to BTT devices drivers/nvdimm/claim.c is created to house the common
    bits.

    Cc: Ross Zwisler
    Signed-off-by: Dan Williams

    Dan Williams
     

26 Jun, 2015

2 commits

  • The libnvdimm 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 libnvdimm 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
    Cc: Boaz Harrosh
    Cc: H. Peter Anvin
    Cc: Jens Axboe
    Cc: Ingo Molnar
    Cc: Christoph Hellwig
    Signed-off-by: Ross Zwisler
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Dan Williams

    Ross Zwisler
     
  • BTT stands for Block Translation Table, and is a way to provide power
    fail sector atomicity semantics for block devices that have the ability
    to perform byte granularity IO. It relies on the capability of libnvdimm
    namespace devices to do byte aligned IO.

    The BTT works as a stacked blocked device, and reserves a chunk of space
    from the backing device for its accounting metadata. It is a bio-based
    driver because all IO is done synchronously, and there is no queuing or
    asynchronous completions at either the device or the driver level.

    The BTT uses 'lanes' to index into various 'on-disk' data structures,
    and lanes also act as a synchronization mechanism in case there are more
    CPUs than available lanes. We did a comparison between two lane lock
    strategies - first where we kept an atomic counter around that tracked
    which was the last lane that was used, and 'our' lane was determined by
    atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
    theoretically, no CPU would be blocked waiting for a lane. The other
    strategy was to use the cpu number we're scheduled on to and hash it to
    a lane number. Theoretically, this could block an IO that could've
    otherwise run using a different, free lane. But some fio workloads
    showed that the direct cpu -> lane hash performed faster than tracking
    'last lane' - my reasoning is the cache thrash caused by moving the
    atomic variable made that approach slower than simply waiting out the
    in-progress IO. This supports the conclusion that the driver can be a
    very simple bio-based one that does synchronous IOs instead of queuing.

    Cc: Andy Lutomirski
    Cc: Boaz Harrosh
    Cc: H. Peter Anvin
    Cc: Jens Axboe
    Cc: Ingo Molnar
    Cc: Christoph Hellwig
    Cc: Neil Brown
    Cc: Jeff Moyer
    Cc: Dave Chinner
    Cc: Greg KH
    [jmoyer: fix nmi watchdog timeout in btt_map_init]
    [jmoyer: move btt initialization to module load path]
    [jmoyer: fix memory leak in the btt initialization path]
    [jmoyer: Don't overwrite corrupted arenas]
    Signed-off-by: Vishal Verma
    Signed-off-by: Dan Williams

    Vishal Verma
     

25 Jun, 2015

3 commits

  • NVDIMM namespaces, in addition to accepting "struct bio" based requests,
    also have the capability to perform byte-aligned accesses. By default
    only the bio/block interface is used. However, if another driver can
    make effective use of the byte-aligned capability it can claim namespace
    interface and use the byte-aligned ->rw_bytes() interface.

    The BTT driver is the initial first consumer of this mechanism to allow
    adding atomic sector update semantics to a pmem or blk namespace. This
    patch is the sysfs infrastructure to allow configuring a BTT instance
    for a namespace. Enabling that BTT and performing i/o is in a
    subsequent patch.

    Cc: Greg KH
    Cc: Neil Brown
    Signed-off-by: Dan Williams

    Dan Williams
     
  • Prepare the pmem driver to consume PMEM namespaces emitted by regions of
    an nvdimm_bus instance. No functional change.

    Acked-by: Christoph Hellwig
    Tested-by: Toshi Kani
    Signed-off-by: Dan Williams

    Dan Williams
     
  • A struct nvdimm_bus is the anchor device for registering nvdimm
    resources and interfaces, for example, a character control device,
    nvdimm devices, and I/O region devices. The ACPI NFIT (NVDIMM Firmware
    Interface Table) is one possible platform description for such
    non-volatile memory resources in a system. The nfit.ko driver attaches
    to the "ACPI0012" device that indicates the presence of the NFIT and
    parses the table to register a struct nvdimm_bus instance.

    Cc:
    Cc: Lv Zheng
    Cc: Robert Moore
    Cc: Rafael J. Wysocki
    Acked-by: Jeff Moyer
    Acked-by: Christoph Hellwig
    Acked-by: Rafael J. Wysocki
    Tested-by: Toshi Kani
    Signed-off-by: Dan Williams

    Dan Williams