2019-05-29 17:18:09 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2015-05-20 05:54:31 +03:00
|
|
|
/*
|
|
|
|
* libnvdimm - Non-volatile-memory Devices Subsystem
|
|
|
|
*
|
|
|
|
* Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
|
|
|
|
*/
|
|
|
|
#ifndef __LIBNVDIMM_H__
|
|
|
|
#define __LIBNVDIMM_H__
|
2015-06-25 11:21:02 +03:00
|
|
|
#include <linux/kernel.h>
|
2015-06-08 21:27:06 +03:00
|
|
|
#include <linux/sizes.h>
|
|
|
|
#include <linux/types.h>
|
2017-06-06 21:10:51 +03:00
|
|
|
#include <linux/uuid.h>
|
2017-08-23 22:48:26 +03:00
|
|
|
#include <linux/spinlock.h>
|
2019-07-05 17:03:22 +03:00
|
|
|
#include <linux/bio.h>
|
2017-08-23 22:48:26 +03:00
|
|
|
|
|
|
|
struct badrange_entry {
|
|
|
|
u64 start;
|
|
|
|
u64 length;
|
|
|
|
struct list_head list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct badrange {
|
|
|
|
struct list_head list;
|
|
|
|
spinlock_t lock;
|
|
|
|
};
|
2015-04-25 10:56:17 +03:00
|
|
|
|
|
|
|
enum {
|
|
|
|
/* when a dimm supports both PMEM and BLK access a label is required */
|
2017-05-05 00:01:24 +03:00
|
|
|
NDD_ALIASING = 0,
|
2015-06-24 03:08:34 +03:00
|
|
|
/* unarmed memory devices may not persist writes */
|
2017-05-05 00:01:24 +03:00
|
|
|
NDD_UNARMED = 1,
|
|
|
|
/* locked memory devices should not be accessed */
|
|
|
|
NDD_LOCKED = 2,
|
2018-12-14 01:36:18 +03:00
|
|
|
/* memory under security wipes should not be accessed */
|
|
|
|
NDD_SECURITY_OVERWRITE = 3,
|
|
|
|
/* tracking whether or not there is a pending device reference */
|
|
|
|
NDD_WORK_PENDING = 4,
|
2019-02-03 03:35:26 +03:00
|
|
|
/* ignore / filter NSLABEL_FLAG_LOCAL for this DIMM, i.e. no aliasing */
|
|
|
|
NDD_NOBLK = 5,
|
2020-01-30 23:06:18 +03:00
|
|
|
/* dimm supports namespace labels */
|
|
|
|
NDD_LABELING = 6,
|
2015-06-08 21:27:06 +03:00
|
|
|
|
|
|
|
/* need to set a limit somewhere, but yes, this is likely overkill */
|
|
|
|
ND_IOCTL_MAX_BUFLEN = SZ_4M,
|
2016-02-18 00:08:58 +03:00
|
|
|
ND_CMD_MAX_ELEM = 5,
|
2016-04-12 01:02:28 +03:00
|
|
|
ND_CMD_MAX_ENVELOPE = 256,
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
ND_MAX_MAPPINGS = 32,
|
2015-05-01 20:34:01 +03:00
|
|
|
|
2015-08-25 02:20:23 +03:00
|
|
|
/* region flag indicating to direct-map persistent memory by default */
|
|
|
|
ND_REGION_PAGEMAP = 0,
|
2018-01-31 22:45:38 +03:00
|
|
|
/*
|
|
|
|
* Platform ensures entire CPU store data path is flushed to pmem on
|
|
|
|
* system power loss.
|
|
|
|
*/
|
|
|
|
ND_REGION_PERSIST_CACHE = 1,
|
2018-01-31 22:45:43 +03:00
|
|
|
/*
|
|
|
|
* Platform provides mechanisms to automatically flush outstanding
|
|
|
|
* write data from memory controler to pmem on system power loss.
|
|
|
|
* (ADR)
|
|
|
|
*/
|
|
|
|
ND_REGION_PERSIST_MEMCTRL = 2,
|
2015-08-25 02:20:23 +03:00
|
|
|
|
2019-07-05 17:03:22 +03:00
|
|
|
/* Platform provides asynchronous flush mechanism */
|
|
|
|
ND_REGION_ASYNC = 3,
|
|
|
|
|
2015-05-01 20:34:01 +03:00
|
|
|
/* mark newly adjusted resources as requiring a label update */
|
|
|
|
DPA_RESOURCE_ADJUSTED = 1 << 0,
|
2015-04-25 10:56:17 +03:00
|
|
|
};
|
|
|
|
|
2015-05-20 05:54:31 +03:00
|
|
|
struct nvdimm;
|
|
|
|
struct nvdimm_bus_descriptor;
|
|
|
|
typedef int (*ndctl_fn)(struct nvdimm_bus_descriptor *nd_desc,
|
|
|
|
struct nvdimm *nvdimm, unsigned int cmd, void *buf,
|
2016-02-13 04:01:11 +03:00
|
|
|
unsigned int buf_len, int *cmd_rc);
|
2015-05-20 05:54:31 +03:00
|
|
|
|
2018-04-06 08:21:13 +03:00
|
|
|
struct device_node;
|
2015-05-20 05:54:31 +03:00
|
|
|
struct nvdimm_bus_descriptor {
|
2015-04-27 02:26:48 +03:00
|
|
|
const struct attribute_group **attr_groups;
|
2017-07-01 06:53:24 +03:00
|
|
|
unsigned long bus_dsm_mask;
|
2016-04-29 02:17:07 +03:00
|
|
|
unsigned long cmd_mask;
|
2016-07-22 06:03:19 +03:00
|
|
|
struct module *module;
|
2015-05-20 05:54:31 +03:00
|
|
|
char *provider_name;
|
2018-04-06 08:21:13 +03:00
|
|
|
struct device_node *of_node;
|
2015-05-20 05:54:31 +03:00
|
|
|
ndctl_fn ndctl;
|
2016-02-19 23:16:34 +03:00
|
|
|
int (*flush_probe)(struct nvdimm_bus_descriptor *nd_desc);
|
2016-02-23 08:50:31 +03:00
|
|
|
int (*clear_to_send)(struct nvdimm_bus_descriptor *nd_desc,
|
acpi/nfit: Add support for Intel DSM 1.8 commands
Add command definition for security commands defined in Intel DSM
specification v1.8 [1]. This includes "get security state", "set
passphrase", "unlock unit", "freeze lock", "secure erase", "overwrite",
"overwrite query", "master passphrase enable/disable", and "master
erase", . Since this adds several Intel definitions, move the relevant
bits to their own header.
These commands mutate physical data, but that manipulation is not cache
coherent. The requirement to flush and invalidate caches makes these
commands unsuitable to be called from userspace, so extra logic is added
to detect and block these commands from being submitted via the ioctl
command submission path.
Lastly, the commands may contain sensitive key material that should not
be dumped in a standard debug session. Update the nvdimm-command
payload-dump facility to move security command payloads behind a
default-off compile time switch.
[1]: http://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-12-04 21:31:11 +03:00
|
|
|
struct nvdimm *nvdimm, unsigned int cmd, void *data);
|
2015-05-20 05:54:31 +03:00
|
|
|
};
|
|
|
|
|
2015-06-08 21:27:06 +03:00
|
|
|
struct nd_cmd_desc {
|
|
|
|
int in_num;
|
|
|
|
int out_num;
|
|
|
|
u32 in_sizes[ND_CMD_MAX_ELEM];
|
|
|
|
int out_sizes[ND_CMD_MAX_ELEM];
|
|
|
|
};
|
|
|
|
|
2015-05-01 20:11:27 +03:00
|
|
|
struct nd_interleave_set {
|
2017-06-04 04:59:15 +03:00
|
|
|
/* v1.1 definition of the interleave-set-cookie algorithm */
|
|
|
|
u64 cookie1;
|
|
|
|
/* v1.2 definition of the interleave-set-cookie algorithm */
|
|
|
|
u64 cookie2;
|
2017-03-01 05:32:48 +03:00
|
|
|
/* compatibility with initial buggy Linux implementation */
|
|
|
|
u64 altcookie;
|
2017-06-06 21:10:51 +03:00
|
|
|
|
|
|
|
guid_t type_guid;
|
2015-05-01 20:11:27 +03:00
|
|
|
};
|
|
|
|
|
2016-09-20 02:38:50 +03:00
|
|
|
struct nd_mapping_desc {
|
|
|
|
struct nvdimm *nvdimm;
|
|
|
|
u64 start;
|
|
|
|
u64 size;
|
2017-08-05 03:20:16 +03:00
|
|
|
int position;
|
2016-09-20 02:38:50 +03:00
|
|
|
};
|
|
|
|
|
2019-07-05 17:03:22 +03:00
|
|
|
struct nd_region;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
struct nd_region_desc {
|
|
|
|
struct resource *res;
|
2016-09-20 02:38:50 +03:00
|
|
|
struct nd_mapping_desc *mapping;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
u16 num_mappings;
|
|
|
|
const struct attribute_group **attr_groups;
|
2015-05-01 20:11:27 +03:00
|
|
|
struct nd_interleave_set *nd_set;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
void *provider_data;
|
nd_btt: atomic sector updates
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 <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[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 <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 11:20:32 +03:00
|
|
|
int num_lanes;
|
2015-06-19 21:18:33 +03:00
|
|
|
int numa_node;
|
2018-11-09 23:43:07 +03:00
|
|
|
int target_node;
|
2015-08-25 02:20:23 +03:00
|
|
|
unsigned long flags;
|
2018-04-06 08:21:13 +03:00
|
|
|
struct device_node *of_node;
|
2019-07-05 17:03:22 +03:00
|
|
|
int (*flush)(struct nd_region *nd_region, struct bio *bio);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
};
|
|
|
|
|
2016-06-07 03:42:38 +03:00
|
|
|
struct device;
|
|
|
|
void *devm_nvdimm_memremap(struct device *dev, resource_size_t offset,
|
|
|
|
size_t size, unsigned long flags);
|
|
|
|
static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
|
|
|
|
resource_size_t offset, size_t size)
|
|
|
|
{
|
|
|
|
return (void __iomem *) devm_nvdimm_memremap(dev, offset, size, 0);
|
|
|
|
}
|
|
|
|
|
2015-06-08 21:27:06 +03:00
|
|
|
struct nvdimm_bus;
|
2015-05-31 22:02:11 +03:00
|
|
|
struct module;
|
2015-06-25 11:21:02 +03:00
|
|
|
struct device;
|
|
|
|
struct nd_blk_region;
|
|
|
|
struct nd_blk_region_desc {
|
|
|
|
int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
|
|
|
|
int (*do_io)(struct nd_blk_region *ndbr, resource_size_t dpa,
|
|
|
|
void *iobuf, u64 len, int rw);
|
|
|
|
struct nd_region_desc ndr_desc;
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct nd_blk_region_desc *to_blk_region_desc(
|
|
|
|
struct nd_region_desc *ndr_desc)
|
|
|
|
{
|
|
|
|
return container_of(ndr_desc, struct nd_blk_region_desc, ndr_desc);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2019-08-27 03:54:54 +03:00
|
|
|
/*
|
|
|
|
* Note that separate bits for locked + unlocked are defined so that
|
|
|
|
* 'flags == 0' corresponds to an error / not-supported state.
|
|
|
|
*/
|
|
|
|
enum nvdimm_security_bits {
|
2018-12-06 10:39:29 +03:00
|
|
|
NVDIMM_SECURITY_DISABLED,
|
|
|
|
NVDIMM_SECURITY_UNLOCKED,
|
|
|
|
NVDIMM_SECURITY_LOCKED,
|
|
|
|
NVDIMM_SECURITY_FROZEN,
|
|
|
|
NVDIMM_SECURITY_OVERWRITE,
|
|
|
|
};
|
|
|
|
|
2018-12-06 23:40:01 +03:00
|
|
|
#define NVDIMM_PASSPHRASE_LEN 32
|
|
|
|
#define NVDIMM_KEY_DESC_LEN 22
|
|
|
|
|
|
|
|
struct nvdimm_key_data {
|
|
|
|
u8 data[NVDIMM_PASSPHRASE_LEN];
|
|
|
|
};
|
|
|
|
|
2018-12-10 20:53:22 +03:00
|
|
|
enum nvdimm_passphrase_type {
|
|
|
|
NVDIMM_USER,
|
|
|
|
NVDIMM_MASTER,
|
|
|
|
};
|
|
|
|
|
2018-12-06 10:39:29 +03:00
|
|
|
struct nvdimm_security_ops {
|
2019-08-27 03:54:54 +03:00
|
|
|
unsigned long (*get_flags)(struct nvdimm *nvdimm,
|
2018-12-10 20:53:22 +03:00
|
|
|
enum nvdimm_passphrase_type pass_type);
|
2018-12-06 20:14:08 +03:00
|
|
|
int (*freeze)(struct nvdimm *nvdimm);
|
2018-12-06 23:40:01 +03:00
|
|
|
int (*change_key)(struct nvdimm *nvdimm,
|
|
|
|
const struct nvdimm_key_data *old_data,
|
2018-12-10 20:53:22 +03:00
|
|
|
const struct nvdimm_key_data *new_data,
|
|
|
|
enum nvdimm_passphrase_type pass_type);
|
2018-12-06 23:40:01 +03:00
|
|
|
int (*unlock)(struct nvdimm *nvdimm,
|
|
|
|
const struct nvdimm_key_data *key_data);
|
2018-12-07 20:33:30 +03:00
|
|
|
int (*disable)(struct nvdimm *nvdimm,
|
|
|
|
const struct nvdimm_key_data *key_data);
|
2018-12-08 00:02:12 +03:00
|
|
|
int (*erase)(struct nvdimm *nvdimm,
|
2018-12-10 20:53:22 +03:00
|
|
|
const struct nvdimm_key_data *key_data,
|
|
|
|
enum nvdimm_passphrase_type pass_type);
|
2018-12-14 01:36:18 +03:00
|
|
|
int (*overwrite)(struct nvdimm *nvdimm,
|
|
|
|
const struct nvdimm_key_data *key_data);
|
|
|
|
int (*query_overwrite)(struct nvdimm *nvdimm);
|
2018-12-06 10:39:29 +03:00
|
|
|
};
|
|
|
|
|
2017-08-23 22:48:26 +03:00
|
|
|
void badrange_init(struct badrange *badrange);
|
|
|
|
int badrange_add(struct badrange *badrange, u64 addr, u64 length);
|
|
|
|
void badrange_forget(struct badrange *badrange, phys_addr_t start,
|
|
|
|
unsigned int len);
|
|
|
|
int nvdimm_bus_add_badrange(struct nvdimm_bus *nvdimm_bus, u64 addr,
|
|
|
|
u64 length);
|
2016-07-22 06:03:19 +03:00
|
|
|
struct nvdimm_bus *nvdimm_bus_register(struct device *parent,
|
|
|
|
struct nvdimm_bus_descriptor *nfit_desc);
|
2015-05-20 05:54:31 +03:00
|
|
|
void nvdimm_bus_unregister(struct nvdimm_bus *nvdimm_bus);
|
2015-04-27 02:26:48 +03:00
|
|
|
struct nvdimm_bus *to_nvdimm_bus(struct device *dev);
|
2018-12-06 10:39:29 +03:00
|
|
|
struct nvdimm_bus *nvdimm_to_bus(struct nvdimm *nvdimm);
|
2015-04-25 10:56:17 +03:00
|
|
|
struct nvdimm *to_nvdimm(struct device *dev);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
struct nd_region *to_nd_region(struct device *dev);
|
2018-04-02 23:14:25 +03:00
|
|
|
struct device *nd_region_dev(struct nd_region *nd_region);
|
2015-06-25 11:21:02 +03:00
|
|
|
struct nd_blk_region *to_nd_blk_region(struct device *dev);
|
2015-04-27 02:26:48 +03:00
|
|
|
struct nvdimm_bus_descriptor *to_nd_desc(struct nvdimm_bus *nvdimm_bus);
|
2016-07-24 07:51:42 +03:00
|
|
|
struct device *to_nvdimm_bus_dev(struct nvdimm_bus *nvdimm_bus);
|
2015-04-25 10:56:17 +03:00
|
|
|
const char *nvdimm_name(struct nvdimm *nvdimm);
|
2016-08-23 05:28:37 +03:00
|
|
|
struct kobject *nvdimm_kobj(struct nvdimm *nvdimm);
|
2016-04-29 02:17:07 +03:00
|
|
|
unsigned long nvdimm_cmd_mask(struct nvdimm *nvdimm);
|
2015-04-25 10:56:17 +03:00
|
|
|
void *nvdimm_provider_data(struct nvdimm *nvdimm);
|
2018-12-04 21:31:20 +03:00
|
|
|
struct nvdimm *__nvdimm_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
void *provider_data, const struct attribute_group **groups,
|
|
|
|
unsigned long flags, unsigned long cmd_mask, int num_flush,
|
2018-12-06 10:39:29 +03:00
|
|
|
struct resource *flush_wpq, const char *dimm_id,
|
|
|
|
const struct nvdimm_security_ops *sec_ops);
|
2018-12-04 21:31:20 +03:00
|
|
|
static inline struct nvdimm *nvdimm_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
void *provider_data, const struct attribute_group **groups,
|
|
|
|
unsigned long flags, unsigned long cmd_mask, int num_flush,
|
|
|
|
struct resource *flush_wpq)
|
|
|
|
{
|
|
|
|
return __nvdimm_create(nvdimm_bus, provider_data, groups, flags,
|
2018-12-06 10:39:29 +03:00
|
|
|
cmd_mask, num_flush, flush_wpq, NULL, NULL);
|
2018-12-04 21:31:20 +03:00
|
|
|
}
|
|
|
|
|
2015-06-08 21:27:06 +03:00
|
|
|
const struct nd_cmd_desc *nd_cmd_dimm_desc(int cmd);
|
|
|
|
const struct nd_cmd_desc *nd_cmd_bus_desc(int cmd);
|
|
|
|
u32 nd_cmd_in_size(struct nvdimm *nvdimm, int cmd,
|
|
|
|
const struct nd_cmd_desc *desc, int idx, void *buf);
|
|
|
|
u32 nd_cmd_out_size(struct nvdimm *nvdimm, int cmd,
|
|
|
|
const struct nd_cmd_desc *desc, int idx, const u32 *in_field,
|
2016-12-06 20:10:12 +03:00
|
|
|
const u32 *out_field, unsigned long remainder);
|
2015-05-31 21:41:48 +03:00
|
|
|
int nvdimm_bus_check_dimm_count(struct nvdimm_bus *nvdimm_bus, int dimm_count);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 03:13:14 +03:00
|
|
|
struct nd_region *nvdimm_pmem_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc);
|
|
|
|
struct nd_region *nvdimm_blk_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc);
|
|
|
|
struct nd_region *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc);
|
2015-06-25 11:21:02 +03:00
|
|
|
void *nd_region_provider_data(struct nd_region *nd_region);
|
|
|
|
void *nd_blk_region_provider_data(struct nd_blk_region *ndbr);
|
|
|
|
void nd_blk_region_set_provider_data(struct nd_blk_region *ndbr, void *data);
|
|
|
|
struct nvdimm *nd_blk_region_to_dimm(struct nd_blk_region *ndbr);
|
2017-01-14 07:36:58 +03:00
|
|
|
unsigned long nd_blk_memremap_flags(struct nd_blk_region *ndbr);
|
2015-06-25 11:21:02 +03:00
|
|
|
unsigned int nd_region_acquire_lane(struct nd_region *nd_region);
|
|
|
|
void nd_region_release_lane(struct nd_region *nd_region, unsigned int lane);
|
2015-05-01 20:11:27 +03:00
|
|
|
u64 nd_fletcher64(void *addr, size_t len, bool le);
|
2019-07-05 17:03:22 +03:00
|
|
|
int nvdimm_flush(struct nd_region *nd_region, struct bio *bio);
|
|
|
|
int generic_nvdimm_flush(struct nd_region *nd_region);
|
2016-07-08 05:44:50 +03:00
|
|
|
int nvdimm_has_flush(struct nd_region *nd_region);
|
2017-06-09 19:46:50 +03:00
|
|
|
int nvdimm_has_cache(struct nd_region *nd_region);
|
2018-12-14 01:36:18 +03:00
|
|
|
int nvdimm_in_overwrite(struct nvdimm *nvdimm);
|
2019-07-05 17:03:24 +03:00
|
|
|
bool is_nvdimm_sync(struct nd_region *nd_region);
|
2017-08-31 14:27:09 +03:00
|
|
|
|
2018-12-06 10:39:29 +03:00
|
|
|
static inline int nvdimm_ctl(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
|
|
|
|
unsigned int buf_len, int *cmd_rc)
|
|
|
|
{
|
|
|
|
struct nvdimm_bus *nvdimm_bus = nvdimm_to_bus(nvdimm);
|
|
|
|
struct nvdimm_bus_descriptor *nd_desc = to_nd_desc(nvdimm_bus);
|
|
|
|
|
|
|
|
return nd_desc->ndctl(nd_desc, nvdimm, cmd, buf, buf_len, cmd_rc);
|
|
|
|
}
|
|
|
|
|
2017-08-31 14:27:09 +03:00
|
|
|
#ifdef CONFIG_ARCH_HAS_PMEM_API
|
|
|
|
#define ARCH_MEMREMAP_PMEM MEMREMAP_WB
|
|
|
|
void arch_wb_cache_pmem(void *addr, size_t size);
|
|
|
|
void arch_invalidate_pmem(void *addr, size_t size);
|
|
|
|
#else
|
|
|
|
#define ARCH_MEMREMAP_PMEM MEMREMAP_WT
|
|
|
|
static inline void arch_wb_cache_pmem(void *addr, size_t size)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline void arch_invalidate_pmem(void *addr, size_t size)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-05-20 05:54:31 +03:00
|
|
|
#endif /* __LIBNVDIMM_H__ */
|