Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Wed, Apr 29, 2015 at 8:55 AM, Dan Williams wrote: > On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski wrote: >> On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny >> wrote: >>> On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski >>> wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams wrote: > [..] >> This is such a mess that I think this driver should maybe flat-out >> refuse to load in this type of configuration without some scary module >> option. I have some NVDIMMs that report as type 12 but need two extra >> out-of-tree drivers to work safely. First, they need i2c_imc or the >> equivalent (I'll try to resubmit that soon). Second, they need secret >> magic NDAed register poking. The latter is very problematic. >> >> At the very least, I think we should discourage people who don't >> really know what they're doing from using this driver without care. > > The benefit of the type-12 experiment having not made it very far out > of the lab is that it may be feasible to whitelist known platforms > where we believe ADR is available. Otherwise, the presence of the > NFIT asserts platform persistent memory support. This could be a good idea. I'm planning on resubmitting my i2c driver in the next couple weeks, and maybe I'll whitelist my own platform :) --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski wrote: > On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny > wrote: >> On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski wrote: >>> On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams >>> wrote: [..] > This is such a mess that I think this driver should maybe flat-out > refuse to load in this type of configuration without some scary module > option. I have some NVDIMMs that report as type 12 but need two extra > out-of-tree drivers to work safely. First, they need i2c_imc or the > equivalent (I'll try to resubmit that soon). Second, they need secret > magic NDAed register poking. The latter is very problematic. > > At the very least, I think we should discourage people who don't > really know what they're doing from using this driver without care. The benefit of the type-12 experiment having not made it very far out of the lab is that it may be feasible to whitelist known platforms where we believe ADR is available. Otherwise, the presence of the NFIT asserts platform persistent memory support. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: [..] This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. The benefit of the type-12 experiment having not made it very far out of the lab is that it may be feasible to whitelist known platforms where we believe ADR is available. Otherwise, the presence of the NFIT asserts platform persistent memory support. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Wed, Apr 29, 2015 at 8:55 AM, Dan Williams dan.j.willi...@intel.com wrote: On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: [..] This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. The benefit of the type-12 experiment having not made it very far out of the lab is that it may be feasible to whitelist known platforms where we believe ADR is available. Otherwise, the presence of the NFIT asserts platform persistent memory support. This could be a good idea. I'm planning on resubmitting my i2c driver in the next couple weeks, and maybe I'll whitelist my own platform :) --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 5:17 PM, Phil Pokorny wrote: > On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski wrote: >> On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny >> wrote: >>> On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski >>> wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams wrote: > +config ND_E820 > + tristate "E820: Support the E820-type-12 PMEM convention" > + depends on X86_PMEM_LEGACY > + default m if X86_PMEM_LEGACY > + select LIBND > + help > + Prior to ACPI 6 some platforms advertised peristent memory > + via type-12 e820 memory ranges. Create a libnd bus and > + attach an instance of the pmem driver to these ranges. > + How about something like: "This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably." >>> >>> Perhaps not "problematic" but "requires a BIOS in Legacy mode" >>> >>> It might also mention that if you use the kernel command line >>> memmap=nn!ss syntax it adds >>> a type 12 region to the e820 map and so you would want this support. >>> >>> If you have a motherboard with UEFI support for NVDIMM's that would be >>> the recommended >>> configuration. >> >> This is such a mess that I think this driver should maybe flat-out >> refuse to load in this type of configuration without some scary module >> option. I have some NVDIMMs that report as type 12 but need two extra >> out-of-tree drivers to work safely. First, they need i2c_imc or the >> equivalent (I'll try to resubmit that soon). Second, they need secret >> magic NDAed register poking. The latter is very problematic. > > My current experience is that things may be changing to something of a > de-facto > standard in the area of register poking. In which case, we should be > able to ask > the de-facto vendor standard to be released under a non-NDA license so we can > write a proper user-space library for it. Or at worst, get a > proprietary source utility > that can do the poking. > > The vendor isn't going to sell anything if they don't provide the > tools their resellers > and customers need. > I suspect that the vendor will soon be done selling this particular part as they move toward something more standard. Dunno. > >> At the very least, I think we should discourage people who don't >> really know what they're doing from using this driver without care. > > What would be the fun in that... > > But seriously, speaking as Penguin Computing and a retailer of > hardware, I'd rather > not have the kernel telling my customers what's safe and what isn't > when it's a matter > of opinion. We provide a solution with support and having to tell my > customers: "you > need to load the module with the 'THIS_IS_UNSAFE' argument set to 3" > isn't productive. It could be that you load with i_promise_i_have_an_nvdimm_driver_too=1 or, better yet, if loaded without the magic option but with the magic driver it figures it out and initializes anyway. > > Another intersesting possibility of the memmap= directive to declare a > type 12 region of > of memory is that you can test the driver (without the persistance) on > any arbitrary region > of memory in a machine. Other comments on this patch set talked about > having to put > virtual test hardware in qemu or kvm. Aside from the register poking, > just adding > memmap=xx!yy to the command line gives you something pmem can attach to and > you can use to test with. I suppose you could even simulate > persistance by saving off > the contents and restoring it on a controlled reboot. That's definitely useful. Anyway, I don't object strongly to the driver as is. Anyone with a legacy NVDIMM is already dependent on all kinds of things going right (correct power supply, ADR, all pins wired correctly, correct BIOS version, no EFI, lack of pcommit not being a problem, etc). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski wrote: > On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny > wrote: >> On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski wrote: >>> On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams >>> wrote: +config ND_E820 + tristate "E820: Support the E820-type-12 PMEM convention" + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + >>> >>> How about something like: >>> >>> "This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. >>> This enables such devices to be exposed as block devices using PMEM. >>> >>> The legacy NVDIMM interface is problematic. This driver will not work >>> if you boot using UEFI, and some NVDIMMs and motherboards that work >>> with this driver may require proprietary code in order to work >>> reliably." >> >> Perhaps not "problematic" but "requires a BIOS in Legacy mode" >> >> It might also mention that if you use the kernel command line >> memmap=nn!ss syntax it adds >> a type 12 region to the e820 map and so you would want this support. >> >> If you have a motherboard with UEFI support for NVDIMM's that would be >> the recommended >> configuration. > > This is such a mess that I think this driver should maybe flat-out > refuse to load in this type of configuration without some scary module > option. I have some NVDIMMs that report as type 12 but need two extra > out-of-tree drivers to work safely. First, they need i2c_imc or the > equivalent (I'll try to resubmit that soon). Second, they need secret > magic NDAed register poking. The latter is very problematic. My current experience is that things may be changing to something of a de-facto standard in the area of register poking. In which case, we should be able to ask the de-facto vendor standard to be released under a non-NDA license so we can write a proper user-space library for it. Or at worst, get a proprietary source utility that can do the poking. The vendor isn't going to sell anything if they don't provide the tools their resellers and customers need. > At the very least, I think we should discourage people who don't > really know what they're doing from using this driver without care. What would be the fun in that... But seriously, speaking as Penguin Computing and a retailer of hardware, I'd rather not have the kernel telling my customers what's safe and what isn't when it's a matter of opinion. We provide a solution with support and having to tell my customers: "you need to load the module with the 'THIS_IS_UNSAFE' argument set to 3" isn't productive. Another intersesting possibility of the memmap= directive to declare a type 12 region of of memory is that you can test the driver (without the persistance) on any arbitrary region of memory in a machine. Other comments on this patch set talked about having to put virtual test hardware in qemu or kvm. Aside from the register poking, just adding memmap=xx!yy to the command line gives you something pmem can attach to and you can use to test with. I suppose you could even simulate persistance by saving off the contents and restoring it on a controlled reboot. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny wrote: > On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski wrote: >> On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams >> wrote: >>> +config ND_E820 >>> + tristate "E820: Support the E820-type-12 PMEM convention" >>> + depends on X86_PMEM_LEGACY >>> + default m if X86_PMEM_LEGACY >>> + select LIBND >>> + help >>> + Prior to ACPI 6 some platforms advertised peristent memory >>> + via type-12 e820 memory ranges. Create a libnd bus and >>> + attach an instance of the pmem driver to these ranges. >>> + >> >> How about something like: >> >> "This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. >> This enables such devices to be exposed as block devices using PMEM. >> >> The legacy NVDIMM interface is problematic. This driver will not work >> if you boot using UEFI, and some NVDIMMs and motherboards that work >> with this driver may require proprietary code in order to work >> reliably." > > Perhaps not "problematic" but "requires a BIOS in Legacy mode" > > It might also mention that if you use the kernel command line > memmap=nn!ss syntax it adds > a type 12 region to the e820 map and so you would want this support. > > If you have a motherboard with UEFI support for NVDIMM's that would be > the recommended > configuration. This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski wrote: > On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams > wrote: >> +config ND_E820 >> + tristate "E820: Support the E820-type-12 PMEM convention" >> + depends on X86_PMEM_LEGACY >> + default m if X86_PMEM_LEGACY >> + select LIBND >> + help >> + Prior to ACPI 6 some platforms advertised peristent memory >> + via type-12 e820 memory ranges. Create a libnd bus and >> + attach an instance of the pmem driver to these ranges. >> + > > How about something like: > > "This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. > This enables such devices to be exposed as block devices using PMEM. > > The legacy NVDIMM interface is problematic. This driver will not work > if you boot using UEFI, and some NVDIMMs and motherboards that work > with this driver may require proprietary code in order to work > reliably." Perhaps not "problematic" but "requires a BIOS in Legacy mode" It might also mention that if you use the kernel command line memmap=nn!ss syntax it adds a type 12 region to the e820 map and so you would want this support. If you have a motherboard with UEFI support for NVDIMM's that would be the recommended configuration. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams wrote: > nd_pmem attaches to persistent memory regions and namespaces emitted by > the nd subsystem, and, same as the original pmem driver, presents the > system-physical-address range as a block device. > > The existing e820-type-12 to pmem setup is converted to a full libnd bus > that emits an nd_namespace_io device. Now that I think I understand what's going on, can I propose alternate help-text wording? [reordered the quotes] > +config BLK_DEV_PMEM > + tristate "PMEM: Persistent memory block device support" > + depends on LIBND > + default LIBND > + help > + Memory ranges for PMEM are described by either an NFIT > + (NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a > + non-standard OEM-specific E820 memory type (type-12, see > + CONFIG_X86_PMEM_LEGACY), or it is manually specified by the > + 'memmap=nn[KMG]!ss[KMG]' kernel command line (see > + Documentation/kernel-parameters.txt). This driver converts > + these persistent memory ranges into block devices that are > + capable of DAX (direct-access) file system mappings. See > + Documentation/blockdev/nd.txt for more details. How about something like: "This driver exposes memory devices that expose byte-addressable nonvolatile storage as block devices. This type of block device supports direct access (i.e. DAX) if an appropriate filesystem is used. This driver requires a libnd driver that supports the memory device being used." Then there would be a sub-menu with the legacy and NFIT drivers. (Or, if this isn't actually configurable that way, then there could be a reference to what needs to be configured to make this work.) > +config ND_E820 > + tristate "E820: Support the E820-type-12 PMEM convention" > + depends on X86_PMEM_LEGACY > + default m if X86_PMEM_LEGACY > + select LIBND > + help > + Prior to ACPI 6 some platforms advertised peristent memory > + via type-12 e820 memory ranges. Create a libnd bus and > + attach an instance of the pmem driver to these ranges. > + How about something like: "This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably." --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
nd_pmem attaches to persistent memory regions and namespaces emitted by
the nd subsystem, and, same as the original pmem driver, presents the
system-physical-address range as a block device.
The existing e820-type-12 to pmem setup is converted to a full libnd bus
that emits an nd_namespace_io device.
Cc: Andy Lutomirski
Cc: Boaz Harrosh
Cc: H. Peter Anvin
Cc: Jens Axboe
Cc: Ingo Molnar
Cc: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/x86/kernel/pmem.c|2 -
drivers/block/Kconfig | 11 -
drivers/block/Makefile|1
drivers/block/nd/Kconfig | 27
drivers/block/nd/Makefile |6 +++
drivers/block/nd/e820.c | 100 +
drivers/block/nd/pmem.c | 47 ++---
7 files changed, 157 insertions(+), 37 deletions(-)
create mode 100644 drivers/block/nd/e820.c
rename drivers/block/{pmem.c => nd/pmem.c} (88%)
diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c
index 3420c874ddc5..279328c42f87 100644
--- a/arch/x86/kernel/pmem.c
+++ b/arch/x86/kernel/pmem.c
@@ -13,7 +13,7 @@ static __init void register_pmem_device(struct resource *res)
struct platform_device *pdev;
int error;
- pdev = platform_device_alloc("pmem", PLATFORM_DEVID_AUTO);
+ pdev = platform_device_alloc("e820_pmem", PLATFORM_DEVID_AUTO);
if (!pdev)
return;
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index dfe40e5ca9bd..1cef4ffb16c5 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -406,17 +406,6 @@ config BLK_DEV_RAM_DAX
and will prevent RAM block device backing store memory from being
allocated from highmem (only a problem for highmem systems).
-config BLK_DEV_PMEM
- tristate "Persistent memory block device support"
- help
- Saying Y here will allow you to use a contiguous range of reserved
- memory as one or more persistent block devices.
-
- To compile this driver as a module, choose M here: the module will be
- called 'pmem'.
-
- If unsure, say N.
-
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media"
depends on !UML
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 07a6acecf4d8..964d8eb2c16f 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_PS3_VRAM)+= ps3vram.o
obj-$(CONFIG_ATARI_FLOPPY) += ataflop.o
obj-$(CONFIG_AMIGA_Z2RAM) += z2ram.o
obj-$(CONFIG_BLK_DEV_RAM) += brd.o
-obj-$(CONFIG_BLK_DEV_PMEM) += pmem.o
obj-$(CONFIG_BLK_DEV_LOOP) += loop.o
obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o
obj-$(CONFIG_BLK_CPQ_CISS_DA) += cciss.o
diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
index d2d84451e82c..c5eaf195734d 100644
--- a/drivers/block/nd/Kconfig
+++ b/drivers/block/nd/Kconfig
@@ -68,4 +68,31 @@ config NFIT_TEST
Say N unless you are doing development of the 'nd' subsystem.
+config ND_E820
+ tristate "E820: Support the E820-type-12 PMEM convention"
+ depends on X86_PMEM_LEGACY
+ default m if X86_PMEM_LEGACY
+ select LIBND
+ help
+ Prior to ACPI 6 some platforms advertised peristent memory
+ via type-12 e820 memory ranges. Create a libnd bus and
+ attach an instance of the pmem driver to these ranges.
+
+config BLK_DEV_PMEM
+ tristate "PMEM: Persistent memory block device support"
+ depends on LIBND
+ default LIBND
+ help
+ Memory ranges for PMEM are described by either an NFIT
+ (NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a
+ non-standard OEM-specific E820 memory type (type-12, see
+ CONFIG_X86_PMEM_LEGACY), or it is manually specified by the
+ 'memmap=nn[KMG]!ss[KMG]' kernel command line (see
+ Documentation/kernel-parameters.txt). This driver converts
+ these persistent memory ranges into block devices that are
+ capable of DAX (direct-access) file system mappings. See
+ Documentation/blockdev/nd.txt for more details.
+
+ Say Y if you want to use a NVDIMM described by NFIT
+
endif
diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
index 0fb0891e1817..ebb212af9f15 100644
--- a/drivers/block/nd/Makefile
+++ b/drivers/block/nd/Makefile
@@ -14,10 +14,16 @@ endif
obj-$(CONFIG_LIBND) += libnd.o
obj-$(CONFIG_ND_ACPI) += nd_acpi.o
+obj-$(CONFIG_ND_E820) += nd_e820.o
obj-$(CONFIG_NFIT_TEST) += test/
+obj-$(CONFIG_BLK_DEV_PMEM) += nd_pmem.o
nd_acpi-y := acpi.o
+nd_e820-y := e820.o
+
+nd_pmem-y := pmem.o
+
libnd-y := core.o
libnd-y += bus.o
libnd-y += dimm_devs.o
diff --git a/drivers/block/nd/e820.c b/drivers/block/nd/e820.c
new file mode 100644
index ..f4db8c54248e
--- /dev/null
+++ b/drivers/block/nd/e820.c
@@ -0,0 +1,100 @@
+/*
+ * libnd e820 support
+ *
+ * Copyright (c) 2014-2015, Intel
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: +config ND_E820 + tristate E820: Support the E820-type-12 PMEM convention + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + How about something like: This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably. Perhaps not problematic but requires a BIOS in Legacy mode It might also mention that if you use the kernel command line memmap=nn!ss syntax it adds a type 12 region to the e820 map and so you would want this support. If you have a motherboard with UEFI support for NVDIMM's that would be the recommended configuration. This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. My current experience is that things may be changing to something of a de-facto standard in the area of register poking. In which case, we should be able to ask the de-facto vendor standard to be released under a non-NDA license so we can write a proper user-space library for it. Or at worst, get a proprietary source utility that can do the poking. The vendor isn't going to sell anything if they don't provide the tools their resellers and customers need. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. What would be the fun in that... But seriously, speaking as Penguin Computing and a retailer of hardware, I'd rather not have the kernel telling my customers what's safe and what isn't when it's a matter of opinion. We provide a solution with support and having to tell my customers: you need to load the module with the 'THIS_IS_UNSAFE' argument set to 3 isn't productive. Another intersesting possibility of the memmap= directive to declare a type 12 region of of memory is that you can test the driver (without the persistance) on any arbitrary region of memory in a machine. Other comments on this patch set talked about having to put virtual test hardware in qemu or kvm. Aside from the register poking, just adding memmap=xx!yy to the command line gives you something pmem can attach to and you can use to test with. I suppose you could even simulate persistance by saving off the contents and restoring it on a controlled reboot. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: +config ND_E820 + tristate E820: Support the E820-type-12 PMEM convention + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + How about something like: This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably. Perhaps not problematic but requires a BIOS in Legacy mode It might also mention that if you use the kernel command line memmap=nn!ss syntax it adds a type 12 region to the e820 map and so you would want this support. If you have a motherboard with UEFI support for NVDIMM's that would be the recommended configuration. This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 5:17 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 3:58 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 3:21 PM, Phil Pokorny ppoko...@penguincomputing.com wrote: On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: +config ND_E820 + tristate E820: Support the E820-type-12 PMEM convention + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + How about something like: This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably. Perhaps not problematic but requires a BIOS in Legacy mode It might also mention that if you use the kernel command line memmap=nn!ss syntax it adds a type 12 region to the e820 map and so you would want this support. If you have a motherboard with UEFI support for NVDIMM's that would be the recommended configuration. This is such a mess that I think this driver should maybe flat-out refuse to load in this type of configuration without some scary module option. I have some NVDIMMs that report as type 12 but need two extra out-of-tree drivers to work safely. First, they need i2c_imc or the equivalent (I'll try to resubmit that soon). Second, they need secret magic NDAed register poking. The latter is very problematic. My current experience is that things may be changing to something of a de-facto standard in the area of register poking. In which case, we should be able to ask the de-facto vendor standard to be released under a non-NDA license so we can write a proper user-space library for it. Or at worst, get a proprietary source utility that can do the poking. The vendor isn't going to sell anything if they don't provide the tools their resellers and customers need. I suspect that the vendor will soon be done selling this particular part as they move toward something more standard. Dunno. At the very least, I think we should discourage people who don't really know what they're doing from using this driver without care. What would be the fun in that... But seriously, speaking as Penguin Computing and a retailer of hardware, I'd rather not have the kernel telling my customers what's safe and what isn't when it's a matter of opinion. We provide a solution with support and having to tell my customers: you need to load the module with the 'THIS_IS_UNSAFE' argument set to 3 isn't productive. It could be that you load with i_promise_i_have_an_nvdimm_driver_too=1 or, better yet, if loaded without the magic option but with the magic driver it figures it out and initializes anyway. Another intersesting possibility of the memmap= directive to declare a type 12 region of of memory is that you can test the driver (without the persistance) on any arbitrary region of memory in a machine. Other comments on this patch set talked about having to put virtual test hardware in qemu or kvm. Aside from the register poking, just adding memmap=xx!yy to the command line gives you something pmem can attach to and you can use to test with. I suppose you could even simulate persistance by saving off the contents and restoring it on a controlled reboot. That's definitely useful. Anyway, I don't object strongly to the driver as is. Anyone with a legacy NVDIMM is already dependent on all kinds of things going right (correct power supply, ADR, all pins wired correctly, correct BIOS version, no EFI, lack of pcommit not being a problem, etc). --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: nd_pmem attaches to persistent memory regions and namespaces emitted by the nd subsystem, and, same as the original pmem driver, presents the system-physical-address range as a block device. The existing e820-type-12 to pmem setup is converted to a full libnd bus that emits an nd_namespace_io device. Now that I think I understand what's going on, can I propose alternate help-text wording? [reordered the quotes] +config BLK_DEV_PMEM + tristate PMEM: Persistent memory block device support + depends on LIBND + default LIBND + help + Memory ranges for PMEM are described by either an NFIT + (NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a + non-standard OEM-specific E820 memory type (type-12, see + CONFIG_X86_PMEM_LEGACY), or it is manually specified by the + 'memmap=nn[KMG]!ss[KMG]' kernel command line (see + Documentation/kernel-parameters.txt). This driver converts + these persistent memory ranges into block devices that are + capable of DAX (direct-access) file system mappings. See + Documentation/blockdev/nd.txt for more details. How about something like: This driver exposes memory devices that expose byte-addressable nonvolatile storage as block devices. This type of block device supports direct access (i.e. DAX) if an appropriate filesystem is used. This driver requires a libnd driver that supports the memory device being used. Then there would be a sub-menu with the legacy and NFIT drivers. (Or, if this isn't actually configurable that way, then there could be a reference to what needs to be configured to make this work.) +config ND_E820 + tristate E820: Support the E820-type-12 PMEM convention + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + How about something like: This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
On Tue, Apr 28, 2015 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Apr 28, 2015 at 11:25 AM, Dan Williams dan.j.willi...@intel.com wrote: +config ND_E820 + tristate E820: Support the E820-type-12 PMEM convention + depends on X86_PMEM_LEGACY + default m if X86_PMEM_LEGACY + select LIBND + help + Prior to ACPI 6 some platforms advertised peristent memory + via type-12 e820 memory ranges. Create a libnd bus and + attach an instance of the pmem driver to these ranges. + How about something like: This driver allows libnd to work with legacy, pre-ACPI 6 NVDIMMs. This enables such devices to be exposed as block devices using PMEM. The legacy NVDIMM interface is problematic. This driver will not work if you boot using UEFI, and some NVDIMMs and motherboards that work with this driver may require proprietary code in order to work reliably. Perhaps not problematic but requires a BIOS in Legacy mode It might also mention that if you use the kernel command line memmap=nn!ss syntax it adds a type 12 region to the e820 map and so you would want this support. If you have a motherboard with UEFI support for NVDIMM's that would be the recommended configuration. Phil P. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/20] libnd, nd_pmem: add libnd support to the pmem driver
nd_pmem attaches to persistent memory regions and namespaces emitted by
the nd subsystem, and, same as the original pmem driver, presents the
system-physical-address range as a block device.
The existing e820-type-12 to pmem setup is converted to a full libnd bus
that emits an nd_namespace_io device.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boaz Harrosh b...@plexistor.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jens Axboe ax...@fb.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Christoph Hellwig h...@lst.de
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
arch/x86/kernel/pmem.c|2 -
drivers/block/Kconfig | 11 -
drivers/block/Makefile|1
drivers/block/nd/Kconfig | 27
drivers/block/nd/Makefile |6 +++
drivers/block/nd/e820.c | 100 +
drivers/block/nd/pmem.c | 47 ++---
7 files changed, 157 insertions(+), 37 deletions(-)
create mode 100644 drivers/block/nd/e820.c
rename drivers/block/{pmem.c = nd/pmem.c} (88%)
diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c
index 3420c874ddc5..279328c42f87 100644
--- a/arch/x86/kernel/pmem.c
+++ b/arch/x86/kernel/pmem.c
@@ -13,7 +13,7 @@ static __init void register_pmem_device(struct resource *res)
struct platform_device *pdev;
int error;
- pdev = platform_device_alloc(pmem, PLATFORM_DEVID_AUTO);
+ pdev = platform_device_alloc(e820_pmem, PLATFORM_DEVID_AUTO);
if (!pdev)
return;
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index dfe40e5ca9bd..1cef4ffb16c5 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -406,17 +406,6 @@ config BLK_DEV_RAM_DAX
and will prevent RAM block device backing store memory from being
allocated from highmem (only a problem for highmem systems).
-config BLK_DEV_PMEM
- tristate Persistent memory block device support
- help
- Saying Y here will allow you to use a contiguous range of reserved
- memory as one or more persistent block devices.
-
- To compile this driver as a module, choose M here: the module will be
- called 'pmem'.
-
- If unsure, say N.
-
config CDROM_PKTCDVD
tristate Packet writing on CD/DVD media
depends on !UML
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 07a6acecf4d8..964d8eb2c16f 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_PS3_VRAM)+= ps3vram.o
obj-$(CONFIG_ATARI_FLOPPY) += ataflop.o
obj-$(CONFIG_AMIGA_Z2RAM) += z2ram.o
obj-$(CONFIG_BLK_DEV_RAM) += brd.o
-obj-$(CONFIG_BLK_DEV_PMEM) += pmem.o
obj-$(CONFIG_BLK_DEV_LOOP) += loop.o
obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o
obj-$(CONFIG_BLK_CPQ_CISS_DA) += cciss.o
diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
index d2d84451e82c..c5eaf195734d 100644
--- a/drivers/block/nd/Kconfig
+++ b/drivers/block/nd/Kconfig
@@ -68,4 +68,31 @@ config NFIT_TEST
Say N unless you are doing development of the 'nd' subsystem.
+config ND_E820
+ tristate E820: Support the E820-type-12 PMEM convention
+ depends on X86_PMEM_LEGACY
+ default m if X86_PMEM_LEGACY
+ select LIBND
+ help
+ Prior to ACPI 6 some platforms advertised peristent memory
+ via type-12 e820 memory ranges. Create a libnd bus and
+ attach an instance of the pmem driver to these ranges.
+
+config BLK_DEV_PMEM
+ tristate PMEM: Persistent memory block device support
+ depends on LIBND
+ default LIBND
+ help
+ Memory ranges for PMEM are described by either an NFIT
+ (NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a
+ non-standard OEM-specific E820 memory type (type-12, see
+ CONFIG_X86_PMEM_LEGACY), or it is manually specified by the
+ 'memmap=nn[KMG]!ss[KMG]' kernel command line (see
+ Documentation/kernel-parameters.txt). This driver converts
+ these persistent memory ranges into block devices that are
+ capable of DAX (direct-access) file system mappings. See
+ Documentation/blockdev/nd.txt for more details.
+
+ Say Y if you want to use a NVDIMM described by NFIT
+
endif
diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
index 0fb0891e1817..ebb212af9f15 100644
--- a/drivers/block/nd/Makefile
+++ b/drivers/block/nd/Makefile
@@ -14,10 +14,16 @@ endif
obj-$(CONFIG_LIBND) += libnd.o
obj-$(CONFIG_ND_ACPI) += nd_acpi.o
+obj-$(CONFIG_ND_E820) += nd_e820.o
obj-$(CONFIG_NFIT_TEST) += test/
+obj-$(CONFIG_BLK_DEV_PMEM) += nd_pmem.o
nd_acpi-y := acpi.o
+nd_e820-y := e820.o
+
+nd_pmem-y := pmem.o
+
libnd-y := core.o
libnd-y += bus.o
libnd-y += dimm_devs.o
diff --git a/drivers/block/nd/e820.c b/drivers/block/nd/e820.c
new file mode 100644
index ..f4db8c54248e
--- /dev/null
+++
