e820: Fix handling of NvDIMM chips

From inspecting the code and the history of e820.c it looks like a BUG.

With old Kernels there was a bug in x86 where any unknown memory chip type would come up BUSY when calling request_mem_region_exclusive().

So for pmem to work with old Kernels and real NvDIMM chips we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.

People have been running with hacked up pmem that will ignore the return code from request_mem_region_exclusive. So here it is official

Signed-off-by Boaz Harrosh <[email protected]>

---
 drivers/block/Kconfig | 12 ++++++++++++
 drivers/block/pmem.c  | 11 +++++++----
 2 files changed, 19 insertions(+), 4 deletions(-)

drivers/block/Kconfig +12 -0

index 3b3200f..10879b8 100644
@@ -430,6 +430,18 @@ config BLK_DEV_PMEM_USE_PAGES
 	  to other devices in the system, then you must say "Yes" here.
 	  If unsure leave as Yes.
 
+config BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+	bool "Ignore the return code from request_mem_region_exclusive"
+	depends on BLK_DEV_PMEM
+	help
+	  In Old Kernels type-12 Memory type which is used by NvDIMM
+	  chips Comes out busy when calling request_mem_region_exclusive,
+	  because of a bug.
+	  If this option is set to "yes". The pmem will ignore the
+	  failure, and continue as usual. If you have an old Kernel and
+	  a real NvDIMM chip you must say yes here.
+	  (Ignored if BLK_DEV_PMEM_USE_PAGES=y)
+
 config CDROM_PKTCDVD
 	tristate "Packet writing on CD/DVD media"
 	depends on !UML

drivers/block/pmem.c +7 -4

index 9eb7ffe..f84d033 100644
@@ -197,10 +197,12 @@ int pmem_mapmem(struct pmem_device *pmem)
 
 	res_mem = request_mem_region_exclusive(pmem->phys_addr, pmem->size,
 					       "pmem");
-	if (!res_mem) {
+	if (unlikely(!res_mem)) {
 		pr_warn("pmem: request_mem_region_exclusive phys=0x%llx size=0x%zx failed\n",
-			   pmem->phys_addr, pmem->size);
-		return -EINVAL;
+			pmem->phys_addr, pmem->size);
+#ifndef CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+		return -EBUSY;
+#endif
 	}
 
 	pmem->virt_addr = ioremap_cache(pmem->phys_addr, pmem->size);

@@ -211,7 +213,8 @@ int pmem_mapmem(struct pmem_device *pmem)
 	return 0;
 
 out_release:
-	release_mem_region(pmem->phys_addr, pmem->size);
+	if (res_mem)
+		release_mem_region(pmem->phys_addr, pmem->size);
 	return err;
 }
 

Quoted 4 lines · Boaz Harrosh

With old Kernels there was a bug in x86 where any unknown memory chip type would come up BUSY when calling request_mem_region_exclusive().

Quoted 8 lines

So for pmem to work with old Kernels and real NvDIMM chips we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.

People have been running with hacked up pmem that will ignore the return code from request_mem_region_exclusive. So here it is official

Signed-off-by Boaz Harrosh <[email protected]>

I'm confused - I thought that this behavior was fixed by patch 1/3? With that patch this memory reservation should not fail, correct?

If so, why do we need this patch?

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type 12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

Quoted 11 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 7 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type 12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Then if we agree about PATCH-1, which is the actual fix. Then the 2nd patch (hence the RFC btw) is nothing more than a name.

I have an old BIOS that knows nothing of NvDIMM, actually a few of them they all report 12.
The fact of the matter is that all the people I've talked with, reported that different vendor chips, all came up type-12. Perhaps type-12 just means "Unknown to current BIOS"

What is the name you suggest "type-12" "unknown-12". Do you understand why they all come out 12 ?

Quoted 24 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

Quoted 3 lines

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Quoted 29 lines · Dan Williams

Quoted 27 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Quoted 3 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Well, except when the kernel does know how to access it:
when an nvdimm driver knows about its own memory region and knows how to handle it, right?

So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it?

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Dan Williams

Quoted 27 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Quoted 7 lines

Quoted 3 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Well, except when the kernel does know how to access
it: when an nvdimm driver knows about its own memory region and knows how to handle it, right?

Yes, except that "type-12" is something picked out of the air that may be invalidated by a future spec change.

If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type.

Quoted 4 lines

So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it?

I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED?

Quoted 44 lines · Dan Williams

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Dan Williams

Quoted 27 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Quoted 7 lines

Quoted 3 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Well, except when the kernel does know how to access
it: when an nvdimm driver knows about its own memory region and knows how to handle it, right?

Yes, except that "type-12" is something picked out of the air that may be invalidated by a future spec change.

Quoted 7 lines

If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type.

But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right?

Quoted 6 lines

Quoted 5 lines

So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it?

Quoted 4 lines

I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED?

Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks.

Quoted 55 lines · Ingo Molnar

Quoted 44 lines · Dan Williams

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Dan Williams

Quoted 27 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Quoted 7 lines

Quoted 3 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Well, except when the kernel does know how to access
it: when an nvdimm driver knows about its own memory region and knows how to handle it, right?

Yes, except that "type-12" is something picked out of the air that may be invalidated by a future spec change.

Quoted 7 lines

If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type.

Quoted 4 lines

But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right?

True.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it?

Quoted 9 lines

Quoted 4 lines

I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED?

Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks.

I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, "do you want drivers to access unknown memory types"?

Quoted 79 lines · Dan Williams

Quoted 55 lines · Ingo Molnar

Quoted 44 lines · Dan Williams

Quoted 32 lines · Ingo Molnar

Quoted 29 lines · Dan Williams

Quoted 27 lines · Boaz Harrosh

Quoted 12 lines · Matthew Wilcox

Quoted 3 lines · Boaz Harrosh

In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use)

Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't have anything in them that says "I am type 12!". How they are reported is up to the BIOS. Just because your BIOS vendor has chosen to report tham as type 12 doesn't mean that any other BIOS vedor is going to have done the same thing.

Quoted 8 lines

Fortunately, the BIOS people have all got together and decided what they're going to do, and it's not type
12. Unfortunately, I think I'm bound by various agreements to not say what they are going to do until they do. But putting this temporary workaround in the kernel to accomodate one BIOS vendor's unreleased experimental code seems like entirely the wrong idea.

I had a feeling I'm entering an holy war ;-).

I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"?

Quoted 7 lines

Quoted 3 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Well, except when the kernel does know how to access
it: when an nvdimm driver knows about its own memory region and knows how to handle it, right?

Yes, except that "type-12" is something picked out of the air that may be invalidated by a future spec change.

Quoted 7 lines

If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type.

Quoted 4 lines

But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right?

True.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it?

Quoted 9 lines

Quoted 4 lines

I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED?

Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks.

Quoted 5 lines

I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, "do you want drivers to access unknown memory types"?

Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region?

Quoted 1 line · Ingo Molnar

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

No, it seems the safe thing to do is prevent the kernel from accessing any memory that it does not know the side-effects of accessing.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Well, except when the kernel does know how to access
it: when an nvdimm driver knows about its own memory region and knows how to handle it, right?

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right?

Quoted 5 lines

Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region?

Sounds good to me.

Do you require another redundant message who's purpose is to scare people off, like:

	e820: WARN [mem 0x0000000100000000-0x000000017fffffff] is unknown type 12

Sure I'll add it

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Quoted 6 lines · Dan Williams

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Quoted 3 lines

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly.

Quoted 13 lines · Christoph Hellwig

Quoted 11 lines · Dan Williams

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Quoted 2 lines

Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly.

Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine.

Quoted 14 lines · Dan Williams

Quoted 13 lines · Christoph Hellwig

Quoted 11 lines · Dan Williams

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Quoted 6 lines

Quoted 2 lines

Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly.

Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine.

If someone cooks up such a patch I can apply it.

Thanks,

Ingo

Quoted 28 lines · Ingo Molnar

Quoted 14 lines · Dan Williams

Quoted 13 lines · Christoph Hellwig

Quoted 11 lines · Dan Williams

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Quoted 6 lines

Quoted 2 lines

Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly.

Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine.

If someone cooks up such a patch I can apply it.

Thanks,

Quoted 2 lines

Ingo

I will submit a new version of my patch-1 with the pr_warn.

Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please?

Quoted 5 lines

I will submit a new version of my patch-1 with the pr_warn.

Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please?

New patch please, and please also Cc: everyone who expressed interest in the thread and who wasn't Cc:-ed to the original patch.

Thanks,

Ingo

Quoted 9 lines · Dan Williams

In fact it was originally "type-6" until ACPI 5 claimed that number for official use, so these platforms, with early proof-of-concept nvdimm support, have already gone through one transition to a new number. They need to do the same once an official number for nvdimm support is published.

Put another way, these early platforms are already using out-of-tree patches for nvdimm enabling. They can continue to do so, or switch to standard methods when the standard is published.

Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly.

I'll submit a patch allowing a nvdimm_type= kernel option that allows to detect them, but will do nothing by default. The code needed is very small and it would be very useful for all kinds of projects.

I do not see why you need the nvdimm_type= kernel option at all.

I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa.
For all these detected regions it will load a pmem device.

It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you?

OK I might be jumping the guns, send the patch and I'll look at it.

Quoted 7 lines · Boaz Harrosh

I do not see why you need the nvdimm_type= kernel option at all.

I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa.
For all these detected regions it will load a pmem device.

Quoted 5 lines

It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you?

OK I might be jumping the guns, send the patch and I'll look at it.

The kernel option means we can autodetect the nvdimms in kernel space with just that option set, no need for needing userspace setup.

How does your script / patch work?

I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit.

On 02/22/2015 06:27 PM, Christoph Hellwig wrote:

Quoted 3 lines

I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit.

From here on that region will look exactly like an DDR3-NvDIMM with