* [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-31 8:23 ` Rafael J. Wysocki
2019-05-30 22:59 ` [PATCH v2 2/8] acpi/hmat: Skip publishing target info for nodes with no online memory Dan Williams
` (6 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: Len Brown, Keith Busch, Rafael J. Wysocki, vishal.l.verma,
ard.biesheuvel, linux-mm, linux-kernel, x86, linux-nvdimm
As a single source file object there is no need for the hmat enabling to
have its own directory.
Cc: Len Brown <lenb@kernel.org>
Cc: Keith Busch <keith.busch@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/acpi/Kconfig | 12 +++++++++++-
drivers/acpi/Makefile | 2 +-
drivers/acpi/hmat.c | 0
drivers/acpi/hmat/Kconfig | 11 -----------
drivers/acpi/hmat/Makefile | 2 --
5 files changed, 12 insertions(+), 15 deletions(-)
rename drivers/acpi/{hmat/hmat.c => hmat.c} (100%)
delete mode 100644 drivers/acpi/hmat/Kconfig
delete mode 100644 drivers/acpi/hmat/Makefile
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 283ee94224c6..ec8691e4152f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -475,7 +475,17 @@ config ACPI_REDUCED_HARDWARE_ONLY
If you are unsure what to do, do not enable this option.
source "drivers/acpi/nfit/Kconfig"
-source "drivers/acpi/hmat/Kconfig"
+
+config ACPI_HMAT
+ bool "ACPI Heterogeneous Memory Attribute Table Support"
+ depends on ACPI_NUMA
+ select HMEM_REPORTING
+ help
+ If set, this option has the kernel parse and report the
+ platform's ACPI HMAT (Heterogeneous Memory Attributes Table),
+ register memory initiators with their targets, and export
+ performance attributes through the node's sysfs device if
+ provided.
source "drivers/acpi/apei/Kconfig"
source "drivers/acpi/dptf/Kconfig"
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5d361e4e3405..fc89686498dd 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -80,7 +80,7 @@ obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
obj-$(CONFIG_ACPI) += container.o
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
obj-$(CONFIG_ACPI_NFIT) += nfit/
-obj-$(CONFIG_ACPI_HMAT) += hmat/
+obj-$(CONFIG_ACPI_HMAT) += hmat.o
obj-$(CONFIG_ACPI) += acpi_memhotplug.o
obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat.c
similarity index 100%
rename from drivers/acpi/hmat/hmat.c
rename to drivers/acpi/hmat.c
diff --git a/drivers/acpi/hmat/Kconfig b/drivers/acpi/hmat/Kconfig
deleted file mode 100644
index 95a29964dbea..000000000000
--- a/drivers/acpi/hmat/Kconfig
+++ /dev/null
@@ -1,11 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-config ACPI_HMAT
- bool "ACPI Heterogeneous Memory Attribute Table Support"
- depends on ACPI_NUMA
- select HMEM_REPORTING
- help
- If set, this option has the kernel parse and report the
- platform's ACPI HMAT (Heterogeneous Memory Attributes Table),
- register memory initiators with their targets, and export
- performance attributes through the node's sysfs device if
- provided.
diff --git a/drivers/acpi/hmat/Makefile b/drivers/acpi/hmat/Makefile
deleted file mode 100644
index 1c20ef36a385..000000000000
--- a/drivers/acpi/hmat/Makefile
+++ /dev/null
@@ -1,2 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_ACPI_HMAT) := hmat.o
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory
2019-05-30 22:59 ` [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory Dan Williams
@ 2019-05-31 8:23 ` Rafael J. Wysocki
2019-05-31 14:52 ` Dan Williams
0 siblings, 1 reply; 24+ messages in thread
From: Rafael J. Wysocki @ 2019-05-31 8:23 UTC (permalink / raw)
To: Dan Williams
Cc: linux-efi, Len Brown, Keith Busch, vishal.l.verma,
ard.biesheuvel, linux-mm, linux-kernel, x86, linux-nvdimm
On Friday, May 31, 2019 12:59:27 AM CEST Dan Williams wrote:
> As a single source file object there is no need for the hmat enabling to
> have its own directory.
Well, I asked Keith to add that directory as the code in hmat.c is more related to mm than to
the rest of the ACPI subsystem.
Is there any problem with retaining it?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory
2019-05-31 8:23 ` Rafael J. Wysocki
@ 2019-05-31 14:52 ` Dan Williams
0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-31 14:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-efi, Len Brown, Keith Busch, Vishal L Verma,
Ard Biesheuvel, Linux MM, Linux Kernel Mailing List, X86 ML,
linux-nvdimm
On Fri, May 31, 2019 at 1:24 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Friday, May 31, 2019 12:59:27 AM CEST Dan Williams wrote:
> > As a single source file object there is no need for the hmat enabling to
> > have its own directory.
>
> Well, I asked Keith to add that directory as the code in hmat.c is more related to mm than to
> the rest of the ACPI subsystem.
...but hmat/hmat.c does not say anything about mm?
> Is there any problem with retaining it?
It feels redundant for no benefit to type hmat/hmat.c. How about create:
drivers/acpi/numa/ or drivers/acpi/mm/
...and move numa.c and hmat.c there if you want to separate mm
concerns from the rest of drivers/acpi/?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 2/8] acpi/hmat: Skip publishing target info for nodes with no online memory
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
2019-05-30 22:59 ` [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-30 22:59 ` [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP Dan Williams
` (5 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: vishal.l.verma, ard.biesheuvel, linux-mm, linux-kernel, x86,
linux-nvdimm
There are multiple scenarios where the HMAT may contain information
about proximity domains that are not currently online. Rather than fail
to report any HMAT data just elide those offline domains.
If and when those domains are later onlined they can be added to the
HMEM reporting at that point.
This was found while testing EFI_MEMORY_SP support which reserves
"specific purpose" memory from the general allocation pool. If that
reservation results in an empty numa-node then the node is not marked
online leading a spurious:
"acpi/hmat: Ignoring HMAT: Invalid table"
...result for HMAT parsing.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/acpi/hmat.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/hmat.c b/drivers/acpi/hmat.c
index 96b7d39a97c6..2c220cb7b620 100644
--- a/drivers/acpi/hmat.c
+++ b/drivers/acpi/hmat.c
@@ -96,9 +96,6 @@ static __init void alloc_memory_target(unsigned int mem_pxm)
{
struct memory_target *target;
- if (pxm_to_node(mem_pxm) == NUMA_NO_NODE)
- return;
-
target = find_mem_target(mem_pxm);
if (target)
return;
@@ -588,6 +585,17 @@ static __init void hmat_register_targets(void)
struct memory_target *target;
list_for_each_entry(target, &targets, node) {
+ int nid = pxm_to_node(target->memory_pxm);
+
+ /*
+ * Skip offline nodes. This can happen when memory
+ * marked EFI_MEMORY_SP, "specific purpose", is applied
+ * to all the memory in a promixity domain leading to
+ * the node being marked offline / unplugged, or if
+ * memory-only "hotplug" node is offline.
+ */
+ if (nid == NUMA_NO_NODE || !node_online(nid))
+ continue;
hmat_register_target_initiators(target);
hmat_register_target_perf(target);
}
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
2019-05-30 22:59 ` [PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory Dan Williams
2019-05-30 22:59 ` [PATCH v2 2/8] acpi/hmat: Skip publishing target info for nodes with no online memory Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-31 8:16 ` Ard Biesheuvel
2019-05-30 22:59 ` [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax Dan Williams
` (4 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, vishal.l.verma, linux-mm, linux-kernel, x86,
linux-nvdimm
UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
interpretation of the EFI Memory Types as "reserved for a specific
purpose". The intent of this bit is to allow the OS to identify precious
or scarce memory resources and optionally manage it separately from
EfiConventionalMemory. As defined older OSes that do not know about this
attribute are permitted to ignore it and the memory will be handled
according to the OS default policy for the given memory type.
In other words, this "specific purpose" hint is deliberately weaker than
EfiReservedMemoryType in that the system continues to operate if the OS
takes no action on the attribute. The risk of taking no action is
potentially unwanted / unmovable kernel allocations from the designated
resource that prevent the full realization of the "specific purpose".
For example, consider a system with a high-bandwidth memory pool. Older
kernels are permitted to boot and consume that memory as conventional
"System-RAM" newer kernels may arrange for that memory to be set aside
by the system administrator for a dedicated high-bandwidth memory aware
application to consume.
Specifically, this mechanism allows for the elimination of scenarios
where platform firmware tries to game OS policy by lying about ACPI SLIT
values, i.e. claiming that a precious memory resource has a high
distance to trigger the OS to avoid it by default.
Implement simple detection of the bit for EFI memory table dumps and
save the kernel policy for a follow-on change.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/firmware/efi/efi.c | 5 +++--
include/linux/efi.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 55b77c576c42..81db09485881 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -848,15 +848,16 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_RO |
EFI_MEMORY_WP | EFI_MEMORY_RP | EFI_MEMORY_XP |
- EFI_MEMORY_NV |
+ EFI_MEMORY_NV | EFI_MEMORY_SP |
EFI_MEMORY_RUNTIME | EFI_MEMORY_MORE_RELIABLE))
snprintf(pos, size, "|attr=0x%016llx]",
(unsigned long long)attr);
else
snprintf(pos, size,
- "|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+ "|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
+ attr & EFI_MEMORY_SP ? "SP" : "",
attr & EFI_MEMORY_NV ? "NV" : "",
attr & EFI_MEMORY_XP ? "XP" : "",
attr & EFI_MEMORY_RP ? "RP" : "",
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6ebc2098cfe1..91368f5ce114 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -112,6 +112,7 @@ typedef struct {
#define EFI_MEMORY_MORE_RELIABLE \
((u64)0x0000000000010000ULL) /* higher reliability */
#define EFI_MEMORY_RO ((u64)0x0000000000020000ULL) /* read-only */
+#define EFI_MEMORY_SP ((u64)0x0000000000040000ULL) /* special purpose */
#define EFI_MEMORY_RUNTIME ((u64)0x8000000000000000ULL) /* range requires runtime mapping */
#define EFI_MEMORY_DESCRIPTOR_VERSION 1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP
2019-05-30 22:59 ` [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP Dan Williams
@ 2019-05-31 8:16 ` Ard Biesheuvel
0 siblings, 0 replies; 24+ messages in thread
From: Ard Biesheuvel @ 2019-05-31 8:16 UTC (permalink / raw)
To: Dan Williams
Cc: linux-efi, Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
the arch/x86 maintainers, linux-nvdimm
On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a specific
> purpose". The intent of this bit is to allow the OS to identify precious
> or scarce memory resources and optionally manage it separately from
> EfiConventionalMemory. As defined older OSes that do not know about this
> attribute are permitted to ignore it and the memory will be handled
> according to the OS default policy for the given memory type.
>
> In other words, this "specific purpose" hint is deliberately weaker than
> EfiReservedMemoryType in that the system continues to operate if the OS
> takes no action on the attribute. The risk of taking no action is
> potentially unwanted / unmovable kernel allocations from the designated
> resource that prevent the full realization of the "specific purpose".
> For example, consider a system with a high-bandwidth memory pool. Older
> kernels are permitted to boot and consume that memory as conventional
> "System-RAM" newer kernels may arrange for that memory to be set aside
> by the system administrator for a dedicated high-bandwidth memory aware
> application to consume.
>
> Specifically, this mechanism allows for the elimination of scenarios
> where platform firmware tries to game OS policy by lying about ACPI SLIT
> values, i.e. claiming that a precious memory resource has a high
> distance to trigger the OS to avoid it by default.
>
> Implement simple detection of the bit for EFI memory table dumps and
> save the kernel policy for a follow-on change.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/efi.c | 5 +++--
> include/linux/efi.h | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 55b77c576c42..81db09485881 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -848,15 +848,16 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
> if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
> EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_RO |
> EFI_MEMORY_WP | EFI_MEMORY_RP | EFI_MEMORY_XP |
> - EFI_MEMORY_NV |
> + EFI_MEMORY_NV | EFI_MEMORY_SP |
> EFI_MEMORY_RUNTIME | EFI_MEMORY_MORE_RELIABLE))
> snprintf(pos, size, "|attr=0x%016llx]",
> (unsigned long long)attr);
> else
> snprintf(pos, size,
> - "|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
> + "|%3s|%2s|%2s|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
> attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
> attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
> + attr & EFI_MEMORY_SP ? "SP" : "",
> attr & EFI_MEMORY_NV ? "NV" : "",
> attr & EFI_MEMORY_XP ? "XP" : "",
> attr & EFI_MEMORY_RP ? "RP" : "",
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 6ebc2098cfe1..91368f5ce114 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -112,6 +112,7 @@ typedef struct {
> #define EFI_MEMORY_MORE_RELIABLE \
> ((u64)0x0000000000010000ULL) /* higher reliability */
> #define EFI_MEMORY_RO ((u64)0x0000000000020000ULL) /* read-only */
> +#define EFI_MEMORY_SP ((u64)0x0000000000040000ULL) /* special purpose */
> #define EFI_MEMORY_RUNTIME ((u64)0x8000000000000000ULL) /* range requires runtime mapping */
> #define EFI_MEMORY_DESCRIPTOR_VERSION 1
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
` (2 preceding siblings ...)
2019-05-30 22:59 ` [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-31 8:29 ` Ard Biesheuvel
2019-06-03 5:41 ` Mike Rapoport
2019-05-30 22:59 ` [PATCH v2 5/8] lib/memregion: Uplevel the pmem "region" ida to a global allocator Dan Williams
` (3 subsequent siblings)
7 siblings, 2 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: x86, Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, Ard Biesheuvel,
kbuild test robot, vishal.l.verma, linux-mm, linux-kernel, x86,
linux-nvdimm
UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
interpretation of the EFI Memory Types as "reserved for a special
purpose".
The proposed Linux behavior for specific purpose memory is that it is
reserved for direct-access (device-dax) by default and not available for
any kernel usage, not even as an OOM fallback. Later, through udev
scripts or another init mechanism, these device-dax claimed ranges can
be reconfigured and hot-added to the available System-RAM with a unique
node identifier.
This patch introduces 3 new concepts at once given the entanglement
between early boot enumeration relative to memory that can optionally be
reserved from the kernel page allocator by default. The new concepts
are:
- E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
enabled, otherwise treat it as typical ram.
- IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
a device driver to search iomem resources for application specific
memory. Teach the iomem code to identify such ranges as "Application
Reserved".
- MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
traditional System RAM pool the expectation is that they will have
typical SRAT entries. In order to support a policy of device-dax by
default with the option to hotplug later, the numa initialization code
is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
A follow-on change integrates parsing of the ACPI HMAT to identify the
node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
now, just identify and reserve memory of this type.
Cc: <x86@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
arch/x86/Kconfig | 20 ++++++++++++++++++++
arch/x86/boot/compressed/eboot.c | 5 ++++-
arch/x86/boot/compressed/kaslr.c | 2 +-
arch/x86/include/asm/e820/types.h | 9 +++++++++
arch/x86/kernel/e820.c | 9 +++++++--
arch/x86/kernel/setup.c | 1 +
arch/x86/platform/efi/efi.c | 37 +++++++++++++++++++++++++++++++++----
drivers/acpi/numa.c | 15 ++++++++++++++-
include/linux/efi.h | 14 ++++++++++++++
include/linux/ioport.h | 1 +
include/linux/memblock.h | 7 +++++++
mm/memblock.c | 4 ++++
12 files changed, 115 insertions(+), 9 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2bbbd4d1ba31..2d58f32ed6fa 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1955,6 +1955,26 @@ config EFI_MIXED
If unsure, say N.
+config EFI_SPECIFIC_DAX
+ bool "DAX Support for EFI Specific Purpose Memory"
+ depends on EFI
+ ---help---
+ On systems that have mixed performance classes of memory EFI
+ may indicate specific purpose memory with an attribute (See
+ EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this
+ attribute may have unique performance characteristics compared
+ to the system's general purpose "System RAM" pool. On the
+ expectation that such memory has application specific usage,
+ and its base EFI memory type is "conventional" answer Y to
+ arrange for the kernel to reserve it for direct-access
+ (device-dax) by default. The memory range can later be
+ optionally assigned to the page allocator by system
+ administrator policy via the device-dax kmem facility. Say N
+ to have the kernel treat this memory as general purpose by
+ default.
+
+ If unsure, say Y.
+
config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 544ac4fafd11..5afa6de508e4 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -560,7 +560,10 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s
case EFI_BOOT_SERVICES_CODE:
case EFI_BOOT_SERVICES_DATA:
case EFI_CONVENTIONAL_MEMORY:
- e820_type = E820_TYPE_RAM;
+ if (is_efi_dax(d))
+ e820_type = E820_TYPE_SPECIFIC;
+ else
+ e820_type = E820_TYPE_RAM;
break;
case EFI_ACPI_MEMORY_NVS:
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c056ba20..8af8b4d4ebc9 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -757,7 +757,7 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
*
* Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
*/
- if (md->type != EFI_CONVENTIONAL_MEMORY)
+ if (md->type != EFI_CONVENTIONAL_MEMORY || is_efi_dax(md))
continue;
if (efi_mirror_found &&
diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h
index c3aa4b5e49e2..7209e611a89d 100644
--- a/arch/x86/include/asm/e820/types.h
+++ b/arch/x86/include/asm/e820/types.h
@@ -28,6 +28,15 @@ enum e820_type {
*/
E820_TYPE_PRAM = 12,
+ /*
+ * Special-purpose / application-specific memory is indicated to
+ * the system via the EFI_MEMORY_SP attribute. Define an e820
+ * translation of this memory type for the purpose of
+ * reserving this range and marking it with the
+ * IORES_DESC_APPLICATION_RESERVED designation.
+ */
+ E820_TYPE_SPECIFIC = 0xefffffff,
+
/*
* Reserved RAM used by the kernel itself if
* CONFIG_INTEL_TXT=y is enabled, memory of this type
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 8f32e705a980..735f86594cab 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -189,6 +189,7 @@ static void __init e820_print_type(enum e820_type type)
switch (type) {
case E820_TYPE_RAM: /* Fall through: */
case E820_TYPE_RESERVED_KERN: pr_cont("usable"); break;
+ case E820_TYPE_SPECIFIC: pr_cont("application reserved"); break;
case E820_TYPE_RESERVED: pr_cont("reserved"); break;
case E820_TYPE_ACPI: pr_cont("ACPI data"); break;
case E820_TYPE_NVS: pr_cont("ACPI NVS"); break;
@@ -1036,6 +1037,7 @@ static const char *__init e820_type_to_string(struct e820_entry *entry)
case E820_TYPE_UNUSABLE: return "Unusable memory";
case E820_TYPE_PRAM: return "Persistent Memory (legacy)";
case E820_TYPE_PMEM: return "Persistent Memory";
+ case E820_TYPE_SPECIFIC: return "Application Reserved";
case E820_TYPE_RESERVED: return "Reserved";
default: return "Unknown E820 type";
}
@@ -1051,6 +1053,7 @@ static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
case E820_TYPE_UNUSABLE: /* Fall-through: */
case E820_TYPE_PRAM: /* Fall-through: */
case E820_TYPE_PMEM: /* Fall-through: */
+ case E820_TYPE_SPECIFIC: /* Fall-through: */
case E820_TYPE_RESERVED: /* Fall-through: */
default: return IORESOURCE_MEM;
}
@@ -1063,6 +1066,7 @@ static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE;
case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY;
case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
+ case E820_TYPE_SPECIFIC: return IORES_DESC_APPLICATION_RESERVED;
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
case E820_TYPE_RAM: /* Fall-through: */
case E820_TYPE_UNUSABLE: /* Fall-through: */
@@ -1078,13 +1082,14 @@ static bool __init do_mark_busy(enum e820_type type, struct resource *res)
return true;
/*
- * Treat persistent memory like device memory, i.e. reserve it
- * for exclusive use of a driver
+ * Treat persistent memory and other special memory ranges like
+ * device memory, i.e. reserve it for exclusive use of a driver
*/
switch (type) {
case E820_TYPE_RESERVED:
case E820_TYPE_PRAM:
case E820_TYPE_PMEM:
+ case E820_TYPE_SPECIFIC:
return false;
case E820_TYPE_RESERVED_KERN:
case E820_TYPE_RAM:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 08a5f4a131f5..ddde1c7b1f9a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1109,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
if (efi_enabled(EFI_MEMMAP)) {
efi_fake_memmap();
+ efi_find_app_specific();
efi_find_mirror();
efi_esrt_init();
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index e1cb01a22fa8..899f1305c77a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -123,10 +123,15 @@ void __init efi_find_mirror(void)
* more than the max 128 entries that can fit in the e820 legacy
* (zeropage) memory map.
*/
+enum add_efi_mode {
+ ADD_EFI_ALL,
+ ADD_EFI_APP_SPECIFIC,
+};
-static void __init do_add_efi_memmap(void)
+static void __init do_add_efi_memmap(enum add_efi_mode mode)
{
efi_memory_desc_t *md;
+ int add = 0;
for_each_efi_memory_desc(md) {
unsigned long long start = md->phys_addr;
@@ -139,7 +144,9 @@ static void __init do_add_efi_memmap(void)
case EFI_BOOT_SERVICES_CODE:
case EFI_BOOT_SERVICES_DATA:
case EFI_CONVENTIONAL_MEMORY:
- if (md->attribute & EFI_MEMORY_WB)
+ if (is_efi_dax(md))
+ e820_type = E820_TYPE_SPECIFIC;
+ else if (md->attribute & EFI_MEMORY_WB)
e820_type = E820_TYPE_RAM;
else
e820_type = E820_TYPE_RESERVED;
@@ -165,9 +172,24 @@ static void __init do_add_efi_memmap(void)
e820_type = E820_TYPE_RESERVED;
break;
}
+
+ if (e820_type == E820_TYPE_SPECIFIC) {
+ memblock_remove(start, size);
+ memblock_add_range(&memblock.reserved, start, size,
+ MAX_NUMNODES, MEMBLOCK_APP_SPECIFIC);
+ } else if (mode != ADD_EFI_APP_SPECIFIC)
+ continue;
+
+ add++;
e820__range_add(start, size, e820_type);
}
- e820__update_table(e820_table);
+ if (add)
+ e820__update_table(e820_table);
+}
+
+void __init efi_find_app_specific(void)
+{
+ do_add_efi_memmap(ADD_EFI_APP_SPECIFIC);
}
int __init efi_memblock_x86_reserve_range(void)
@@ -200,7 +222,7 @@ int __init efi_memblock_x86_reserve_range(void)
return rv;
if (add_efi_memmap)
- do_add_efi_memmap();
+ do_add_efi_memmap(ADD_EFI_ALL);
WARN(efi.memmap.desc_version != 1,
"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
@@ -753,6 +775,13 @@ static bool should_map_region(efi_memory_desc_t *md)
if (IS_ENABLED(CONFIG_X86_32))
return false;
+ /*
+ * Specific purpose memory assigned to device-dax is
+ * not mapped by default.
+ */
+ if (is_efi_dax(md))
+ return false;
+
/*
* Map all of RAM so that we can access arguments in the 1:1
* mapping when making EFI runtime calls.
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 30995834ad70..9083bb8f611b 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -260,7 +260,7 @@ void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
int __init
acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
{
- u64 start, end;
+ u64 start, end, i, a_start, a_end;
u32 hotpluggable;
int node, pxm;
@@ -283,6 +283,19 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (acpi_srat_revision <= 1)
pxm &= 0xff;
+ /* Clamp Application Specific Memory */
+ for_each_mem_range(i, &memblock.reserved, NULL, NUMA_NO_NODE,
+ MEMBLOCK_APP_SPECIFIC, &a_start, &a_end, NULL) {
+ pr_debug("%s: SP: %#llx %#llx SRAT: %#llx %#llx\n", __func__,
+ a_start, a_end, start, end);
+ if (a_start <= start && a_end >= end)
+ goto out_err;
+ if (a_start >= start && a_start < end)
+ start = a_start;
+ if (a_end <= end && end > start)
+ end = a_end;
+ }
+
node = acpi_map_pxm_to_node(pxm);
if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
pr_err("SRAT: Too many proximity domains.\n");
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 91368f5ce114..b57b123cbdf9 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -129,6 +129,19 @@ typedef struct {
u64 attribute;
} efi_memory_desc_t;
+#ifdef CONFIG_EFI_SPECIFIC_DAX
+static inline bool is_efi_dax(efi_memory_desc_t *md)
+{
+ return md->type == EFI_CONVENTIONAL_MEMORY
+ && (md->attribute & EFI_MEMORY_SP);
+}
+#else
+static inline bool is_efi_dax(efi_memory_desc_t *md)
+{
+ return false;
+}
+#endif
+
typedef struct {
efi_guid_t guid;
u32 headersize;
@@ -1043,6 +1056,7 @@ extern efi_status_t efi_query_variable_store(u32 attributes,
unsigned long size,
bool nonblocking);
extern void efi_find_mirror(void);
+extern void efi_find_app_specific(void);
#else
static inline efi_status_t efi_query_variable_store(u32 attributes,
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..2d79841ee9b9 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -133,6 +133,7 @@ enum {
IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
+ IORES_DESC_APPLICATION_RESERVED = 8,
};
/* helpers to define resources */
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 676d3900e1bd..58c29180f2cd 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -35,12 +35,14 @@ extern unsigned long long max_possible_pfn;
* @MEMBLOCK_HOTPLUG: hotpluggable region
* @MEMBLOCK_MIRROR: mirrored region
* @MEMBLOCK_NOMAP: don't add to kernel direct mapping
+ * @MEMBLOCK_APP_SPECIFIC: reserved / application specific range
*/
enum memblock_flags {
MEMBLOCK_NONE = 0x0, /* No special request */
MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */
MEMBLOCK_MIRROR = 0x2, /* mirrored region */
MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
+ MEMBLOCK_APP_SPECIFIC = 0x8, /* reserved / application specific range */
};
/**
@@ -215,6 +217,11 @@ static inline bool memblock_is_mirror(struct memblock_region *m)
return m->flags & MEMBLOCK_MIRROR;
}
+static inline bool memblock_is_app_specific(struct memblock_region *m)
+{
+ return m->flags & MEMBLOCK_APP_SPECIFIC;
+}
+
static inline bool memblock_is_nomap(struct memblock_region *m)
{
return m->flags & MEMBLOCK_NOMAP;
diff --git a/mm/memblock.c b/mm/memblock.c
index 6bbad46f4d2c..654fecb52ba5 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -982,6 +982,10 @@ static bool should_skip_region(struct memblock_region *m, int nid, int flags)
if ((flags & MEMBLOCK_MIRROR) && !memblock_is_mirror(m))
return true;
+ /* if we want specific memory skip non-specific memory regions */
+ if ((flags & MEMBLOCK_APP_SPECIFIC) && !memblock_is_app_specific(m))
+ return true;
+
/* skip nomap memory unless we were asked for it explicitly */
if (!(flags & MEMBLOCK_NOMAP) && memblock_is_nomap(m))
return true;
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-30 22:59 ` [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax Dan Williams
@ 2019-05-31 8:29 ` Ard Biesheuvel
2019-05-31 15:28 ` Dan Williams
2019-06-03 5:41 ` Mike Rapoport
1 sibling, 1 reply; 24+ messages in thread
From: Ard Biesheuvel @ 2019-05-31 8:29 UTC (permalink / raw)
To: Dan Williams, Mike Rapoport
Cc: linux-efi, the arch/x86 maintainers, Borislav Petkov,
Ingo Molnar, H. Peter Anvin, Darren Hart, Andy Shevchenko,
Thomas Gleixner, kbuild test robot, Vishal L Verma, Linux-MM,
Linux Kernel Mailing List, linux-nvdimm
(cc Mike for memblock)
On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
>
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a special
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback. Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier.
>
> This patch introduces 3 new concepts at once given the entanglement
> between early boot enumeration relative to memory that can optionally be
> reserved from the kernel page allocator by default. The new concepts
> are:
>
> - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> enabled, otherwise treat it as typical ram.
>
OK, so now we have 'special purpose', 'specific' and 'app specific'
[below]. Do they all mean the same thing?
> - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> a device driver to search iomem resources for application specific
> memory. Teach the iomem code to identify such ranges as "Application
> Reserved".
>
> - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> traditional System RAM pool the expectation is that they will have
> typical SRAT entries. In order to support a policy of device-dax by
> default with the option to hotplug later, the numa initialization code
> is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
>
Can we move the generic memblock changes into a separate patch please?
> A follow-on change integrates parsing of the ACPI HMAT to identify the
> node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> now, just identify and reserve memory of this type.
>
> Cc: <x86@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Andy Shevchenko <andy@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/x86/Kconfig | 20 ++++++++++++++++++++
> arch/x86/boot/compressed/eboot.c | 5 ++++-
> arch/x86/boot/compressed/kaslr.c | 2 +-
> arch/x86/include/asm/e820/types.h | 9 +++++++++
> arch/x86/kernel/e820.c | 9 +++++++--
> arch/x86/kernel/setup.c | 1 +
> arch/x86/platform/efi/efi.c | 37 +++++++++++++++++++++++++++++++++----
> drivers/acpi/numa.c | 15 ++++++++++++++-
> include/linux/efi.h | 14 ++++++++++++++
> include/linux/ioport.h | 1 +
> include/linux/memblock.h | 7 +++++++
> mm/memblock.c | 4 ++++
> 12 files changed, 115 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 2bbbd4d1ba31..2d58f32ed6fa 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1955,6 +1955,26 @@ config EFI_MIXED
>
> If unsure, say N.
>
> +config EFI_SPECIFIC_DAX
> + bool "DAX Support for EFI Specific Purpose Memory"
> + depends on EFI
> + ---help---
> + On systems that have mixed performance classes of memory EFI
> + may indicate specific purpose memory with an attribute (See
> + EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this
> + attribute may have unique performance characteristics compared
> + to the system's general purpose "System RAM" pool. On the
> + expectation that such memory has application specific usage,
> + and its base EFI memory type is "conventional" answer Y to
> + arrange for the kernel to reserve it for direct-access
> + (device-dax) by default. The memory range can later be
> + optionally assigned to the page allocator by system
> + administrator policy via the device-dax kmem facility. Say N
> + to have the kernel treat this memory as general purpose by
> + default.
> +
> + If unsure, say Y.
> +
> config SECCOMP
> def_bool y
> prompt "Enable seccomp to safely compute untrusted bytecode"
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 544ac4fafd11..5afa6de508e4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -560,7 +560,10 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s
> case EFI_BOOT_SERVICES_CODE:
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> - e820_type = E820_TYPE_RAM;
> + if (is_efi_dax(d))
> + e820_type = E820_TYPE_SPECIFIC;
> + else
> + e820_type = E820_TYPE_RAM;
> break;
>
> case EFI_ACPI_MEMORY_NVS:
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index 2e53c056ba20..8af8b4d4ebc9 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -757,7 +757,7 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
> *
> * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> */
> - if (md->type != EFI_CONVENTIONAL_MEMORY)
> + if (md->type != EFI_CONVENTIONAL_MEMORY || is_efi_dax(md))
> continue;
>
> if (efi_mirror_found &&
> diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h
> index c3aa4b5e49e2..7209e611a89d 100644
> --- a/arch/x86/include/asm/e820/types.h
> +++ b/arch/x86/include/asm/e820/types.h
> @@ -28,6 +28,15 @@ enum e820_type {
> */
> E820_TYPE_PRAM = 12,
>
> + /*
> + * Special-purpose / application-specific memory is indicated to
> + * the system via the EFI_MEMORY_SP attribute. Define an e820
> + * translation of this memory type for the purpose of
> + * reserving this range and marking it with the
> + * IORES_DESC_APPLICATION_RESERVED designation.
> + */
> + E820_TYPE_SPECIFIC = 0xefffffff,
> +
> /*
> * Reserved RAM used by the kernel itself if
> * CONFIG_INTEL_TXT=y is enabled, memory of this type
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 8f32e705a980..735f86594cab 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -189,6 +189,7 @@ static void __init e820_print_type(enum e820_type type)
> switch (type) {
> case E820_TYPE_RAM: /* Fall through: */
> case E820_TYPE_RESERVED_KERN: pr_cont("usable"); break;
> + case E820_TYPE_SPECIFIC: pr_cont("application reserved"); break;
> case E820_TYPE_RESERVED: pr_cont("reserved"); break;
> case E820_TYPE_ACPI: pr_cont("ACPI data"); break;
> case E820_TYPE_NVS: pr_cont("ACPI NVS"); break;
> @@ -1036,6 +1037,7 @@ static const char *__init e820_type_to_string(struct e820_entry *entry)
> case E820_TYPE_UNUSABLE: return "Unusable memory";
> case E820_TYPE_PRAM: return "Persistent Memory (legacy)";
> case E820_TYPE_PMEM: return "Persistent Memory";
> + case E820_TYPE_SPECIFIC: return "Application Reserved";
> case E820_TYPE_RESERVED: return "Reserved";
> default: return "Unknown E820 type";
> }
> @@ -1051,6 +1053,7 @@ static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
> case E820_TYPE_UNUSABLE: /* Fall-through: */
> case E820_TYPE_PRAM: /* Fall-through: */
> case E820_TYPE_PMEM: /* Fall-through: */
> + case E820_TYPE_SPECIFIC: /* Fall-through: */
> case E820_TYPE_RESERVED: /* Fall-through: */
> default: return IORESOURCE_MEM;
> }
> @@ -1063,6 +1066,7 @@ static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
> case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE;
> case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY;
> case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
> + case E820_TYPE_SPECIFIC: return IORES_DESC_APPLICATION_RESERVED;
> case E820_TYPE_RESERVED_KERN: /* Fall-through: */
> case E820_TYPE_RAM: /* Fall-through: */
> case E820_TYPE_UNUSABLE: /* Fall-through: */
> @@ -1078,13 +1082,14 @@ static bool __init do_mark_busy(enum e820_type type, struct resource *res)
> return true;
>
> /*
> - * Treat persistent memory like device memory, i.e. reserve it
> - * for exclusive use of a driver
> + * Treat persistent memory and other special memory ranges like
> + * device memory, i.e. reserve it for exclusive use of a driver
> */
> switch (type) {
> case E820_TYPE_RESERVED:
> case E820_TYPE_PRAM:
> case E820_TYPE_PMEM:
> + case E820_TYPE_SPECIFIC:
> return false;
> case E820_TYPE_RESERVED_KERN:
> case E820_TYPE_RAM:
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 08a5f4a131f5..ddde1c7b1f9a 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1109,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
>
> if (efi_enabled(EFI_MEMMAP)) {
> efi_fake_memmap();
> + efi_find_app_specific();
> efi_find_mirror();
> efi_esrt_init();
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e1cb01a22fa8..899f1305c77a 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -123,10 +123,15 @@ void __init efi_find_mirror(void)
> * more than the max 128 entries that can fit in the e820 legacy
> * (zeropage) memory map.
> */
> +enum add_efi_mode {
> + ADD_EFI_ALL,
> + ADD_EFI_APP_SPECIFIC,
> +};
>
> -static void __init do_add_efi_memmap(void)
> +static void __init do_add_efi_memmap(enum add_efi_mode mode)
> {
> efi_memory_desc_t *md;
> + int add = 0;
>
> for_each_efi_memory_desc(md) {
> unsigned long long start = md->phys_addr;
> @@ -139,7 +144,9 @@ static void __init do_add_efi_memmap(void)
> case EFI_BOOT_SERVICES_CODE:
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> - if (md->attribute & EFI_MEMORY_WB)
> + if (is_efi_dax(md))
> + e820_type = E820_TYPE_SPECIFIC;
> + else if (md->attribute & EFI_MEMORY_WB)
> e820_type = E820_TYPE_RAM;
> else
> e820_type = E820_TYPE_RESERVED;
> @@ -165,9 +172,24 @@ static void __init do_add_efi_memmap(void)
> e820_type = E820_TYPE_RESERVED;
> break;
> }
> +
> + if (e820_type == E820_TYPE_SPECIFIC) {
> + memblock_remove(start, size);
> + memblock_add_range(&memblock.reserved, start, size,
> + MAX_NUMNODES, MEMBLOCK_APP_SPECIFIC);
> + } else if (mode != ADD_EFI_APP_SPECIFIC)
> + continue;
> +
> + add++;
> e820__range_add(start, size, e820_type);
> }
> - e820__update_table(e820_table);
> + if (add)
> + e820__update_table(e820_table);
> +}
> +
> +void __init efi_find_app_specific(void)
> +{
> + do_add_efi_memmap(ADD_EFI_APP_SPECIFIC);
> }
>
> int __init efi_memblock_x86_reserve_range(void)
> @@ -200,7 +222,7 @@ int __init efi_memblock_x86_reserve_range(void)
> return rv;
>
> if (add_efi_memmap)
> - do_add_efi_memmap();
> + do_add_efi_memmap(ADD_EFI_ALL);
>
> WARN(efi.memmap.desc_version != 1,
> "Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
> @@ -753,6 +775,13 @@ static bool should_map_region(efi_memory_desc_t *md)
> if (IS_ENABLED(CONFIG_X86_32))
> return false;
>
> + /*
> + * Specific purpose memory assigned to device-dax is
> + * not mapped by default.
> + */
> + if (is_efi_dax(md))
> + return false;
> +
> /*
> * Map all of RAM so that we can access arguments in the 1:1
> * mapping when making EFI runtime calls.
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index 30995834ad70..9083bb8f611b 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -260,7 +260,7 @@ void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> int __init
> acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> {
> - u64 start, end;
> + u64 start, end, i, a_start, a_end;
> u32 hotpluggable;
> int node, pxm;
>
> @@ -283,6 +283,19 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> if (acpi_srat_revision <= 1)
> pxm &= 0xff;
>
> + /* Clamp Application Specific Memory */
> + for_each_mem_range(i, &memblock.reserved, NULL, NUMA_NO_NODE,
> + MEMBLOCK_APP_SPECIFIC, &a_start, &a_end, NULL) {
> + pr_debug("%s: SP: %#llx %#llx SRAT: %#llx %#llx\n", __func__,
> + a_start, a_end, start, end);
> + if (a_start <= start && a_end >= end)
> + goto out_err;
> + if (a_start >= start && a_start < end)
> + start = a_start;
> + if (a_end <= end && end > start)
> + end = a_end;
> + }
> +
> node = acpi_map_pxm_to_node(pxm);
> if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> pr_err("SRAT: Too many proximity domains.\n");
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 91368f5ce114..b57b123cbdf9 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -129,6 +129,19 @@ typedef struct {
> u64 attribute;
> } efi_memory_desc_t;
>
> +#ifdef CONFIG_EFI_SPECIFIC_DAX
> +static inline bool is_efi_dax(efi_memory_desc_t *md)
> +{
> + return md->type == EFI_CONVENTIONAL_MEMORY
> + && (md->attribute & EFI_MEMORY_SP);
> +}
> +#else
> +static inline bool is_efi_dax(efi_memory_desc_t *md)
> +{
> + return false;
> +}
> +#endif
> +
> typedef struct {
> efi_guid_t guid;
> u32 headersize;
I'd prefer it if we could avoid this DAX policy distinction leaking
into the EFI layer.
IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
whether that is DAX memory or not should be decided in the DAX layer.
> @@ -1043,6 +1056,7 @@ extern efi_status_t efi_query_variable_store(u32 attributes,
> unsigned long size,
> bool nonblocking);
> extern void efi_find_mirror(void);
> +extern void efi_find_app_specific(void);
> #else
>
> static inline efi_status_t efi_query_variable_store(u32 attributes,
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index da0ebaec25f0..2d79841ee9b9 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -133,6 +133,7 @@ enum {
> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
> IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
> + IORES_DESC_APPLICATION_RESERVED = 8,
> };
>
> /* helpers to define resources */
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 676d3900e1bd..58c29180f2cd 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -35,12 +35,14 @@ extern unsigned long long max_possible_pfn;
> * @MEMBLOCK_HOTPLUG: hotpluggable region
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_APP_SPECIFIC: reserved / application specific range
> */
> enum memblock_flags {
> MEMBLOCK_NONE = 0x0, /* No special request */
> MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */
> MEMBLOCK_MIRROR = 0x2, /* mirrored region */
> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
> + MEMBLOCK_APP_SPECIFIC = 0x8, /* reserved / application specific range */
> };
>
> /**
> @@ -215,6 +217,11 @@ static inline bool memblock_is_mirror(struct memblock_region *m)
> return m->flags & MEMBLOCK_MIRROR;
> }
>
> +static inline bool memblock_is_app_specific(struct memblock_region *m)
> +{
> + return m->flags & MEMBLOCK_APP_SPECIFIC;
> +}
> +
> static inline bool memblock_is_nomap(struct memblock_region *m)
> {
> return m->flags & MEMBLOCK_NOMAP;
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 6bbad46f4d2c..654fecb52ba5 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -982,6 +982,10 @@ static bool should_skip_region(struct memblock_region *m, int nid, int flags)
> if ((flags & MEMBLOCK_MIRROR) && !memblock_is_mirror(m))
> return true;
>
> + /* if we want specific memory skip non-specific memory regions */
> + if ((flags & MEMBLOCK_APP_SPECIFIC) && !memblock_is_app_specific(m))
> + return true;
> +
> /* skip nomap memory unless we were asked for it explicitly */
> if (!(flags & MEMBLOCK_NOMAP) && memblock_is_nomap(m))
> return true;
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-31 8:29 ` Ard Biesheuvel
@ 2019-05-31 15:28 ` Dan Williams
2019-05-31 15:30 ` Ard Biesheuvel
0 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-05-31 15:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> (cc Mike for memblock)
>
> On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > interpretation of the EFI Memory Types as "reserved for a special
> > purpose".
> >
> > The proposed Linux behavior for specific purpose memory is that it is
> > reserved for direct-access (device-dax) by default and not available for
> > any kernel usage, not even as an OOM fallback. Later, through udev
> > scripts or another init mechanism, these device-dax claimed ranges can
> > be reconfigured and hot-added to the available System-RAM with a unique
> > node identifier.
> >
> > This patch introduces 3 new concepts at once given the entanglement
> > between early boot enumeration relative to memory that can optionally be
> > reserved from the kernel page allocator by default. The new concepts
> > are:
> >
> > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > enabled, otherwise treat it as typical ram.
> >
>
> OK, so now we have 'special purpose', 'specific' and 'app specific'
> [below]. Do they all mean the same thing?
I struggled with separating the raw-EFI-type name from the name of the
Linux specific policy. Since the reservation behavior is optional I
was thinking there should be a distinct Linux kernel name for that
policy. I did try to go back and change all occurrences of "special"
to "specific" from the RFC to this v2, but seems I missed one.
>
> > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > a device driver to search iomem resources for application specific
> > memory. Teach the iomem code to identify such ranges as "Application
> > Reserved".
> >
> > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > traditional System RAM pool the expectation is that they will have
> > typical SRAT entries. In order to support a policy of device-dax by
> > default with the option to hotplug later, the numa initialization code
> > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> >
>
> Can we move the generic memblock changes into a separate patch please?
Yeah, that can move to a lead-in patch.
[..]
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 91368f5ce114..b57b123cbdf9 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -129,6 +129,19 @@ typedef struct {
> > u64 attribute;
> > } efi_memory_desc_t;
> >
> > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > +{
> > + return md->type == EFI_CONVENTIONAL_MEMORY
> > + && (md->attribute & EFI_MEMORY_SP);
> > +}
> > +#else
> > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> > typedef struct {
> > efi_guid_t guid;
> > u32 headersize;
>
> I'd prefer it if we could avoid this DAX policy distinction leaking
> into the EFI layer.
>
> IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
> whether that is DAX memory or not should be decided in the DAX layer.
Ok, how about is_efi_sp_ram()? Since EFI_MEMORY_SP might be applied to
things that aren't EFI_CONVENTIONAL_MEMORY.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-31 15:28 ` Dan Williams
@ 2019-05-31 15:30 ` Ard Biesheuvel
2019-06-01 4:26 ` Dan Williams
0 siblings, 1 reply; 24+ messages in thread
From: Ard Biesheuvel @ 2019-05-31 15:30 UTC (permalink / raw)
To: Dan Williams
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, 31 May 2019 at 17:28, Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > (cc Mike for memblock)
> >
> > On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > interpretation of the EFI Memory Types as "reserved for a special
> > > purpose".
> > >
> > > The proposed Linux behavior for specific purpose memory is that it is
> > > reserved for direct-access (device-dax) by default and not available for
> > > any kernel usage, not even as an OOM fallback. Later, through udev
> > > scripts or another init mechanism, these device-dax claimed ranges can
> > > be reconfigured and hot-added to the available System-RAM with a unique
> > > node identifier.
> > >
> > > This patch introduces 3 new concepts at once given the entanglement
> > > between early boot enumeration relative to memory that can optionally be
> > > reserved from the kernel page allocator by default. The new concepts
> > > are:
> > >
> > > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > > enabled, otherwise treat it as typical ram.
> > >
> >
> > OK, so now we have 'special purpose', 'specific' and 'app specific'
> > [below]. Do they all mean the same thing?
>
> I struggled with separating the raw-EFI-type name from the name of the
> Linux specific policy. Since the reservation behavior is optional I
> was thinking there should be a distinct Linux kernel name for that
> policy. I did try to go back and change all occurrences of "special"
> to "specific" from the RFC to this v2, but seems I missed one.
>
OK
> >
> > > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > > a device driver to search iomem resources for application specific
> > > memory. Teach the iomem code to identify such ranges as "Application
> > > Reserved".
> > >
> > > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > > traditional System RAM pool the expectation is that they will have
> > > typical SRAT entries. In order to support a policy of device-dax by
> > > default with the option to hotplug later, the numa initialization code
> > > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> > >
> >
> > Can we move the generic memblock changes into a separate patch please?
>
> Yeah, that can move to a lead-in patch.
>
> [..]
> > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > index 91368f5ce114..b57b123cbdf9 100644
> > > --- a/include/linux/efi.h
> > > +++ b/include/linux/efi.h
> > > @@ -129,6 +129,19 @@ typedef struct {
> > > u64 attribute;
> > > } efi_memory_desc_t;
> > >
> > > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > +{
> > > + return md->type == EFI_CONVENTIONAL_MEMORY
> > > + && (md->attribute & EFI_MEMORY_SP);
> > > +}
> > > +#else
> > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > +{
> > > + return false;
> > > +}
> > > +#endif
> > > +
> > > typedef struct {
> > > efi_guid_t guid;
> > > u32 headersize;
> >
> > I'd prefer it if we could avoid this DAX policy distinction leaking
> > into the EFI layer.
> >
> > IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
> > whether that is DAX memory or not should be decided in the DAX layer.
>
> Ok, how about is_efi_sp_ram()? Since EFI_MEMORY_SP might be applied to
> things that aren't EFI_CONVENTIONAL_MEMORY.
Yes, that is fine. As long as the #ifdef lives in the DAX code and not here.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-31 15:30 ` Ard Biesheuvel
@ 2019-06-01 4:26 ` Dan Williams
2019-06-07 12:29 ` Ard Biesheuvel
0 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-06-01 4:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, May 31, 2019 at 8:30 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Fri, 31 May 2019 at 17:28, Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > >
> > > (cc Mike for memblock)
> > >
> > > On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > interpretation of the EFI Memory Types as "reserved for a special
> > > > purpose".
> > > >
> > > > The proposed Linux behavior for specific purpose memory is that it is
> > > > reserved for direct-access (device-dax) by default and not available for
> > > > any kernel usage, not even as an OOM fallback. Later, through udev
> > > > scripts or another init mechanism, these device-dax claimed ranges can
> > > > be reconfigured and hot-added to the available System-RAM with a unique
> > > > node identifier.
> > > >
> > > > This patch introduces 3 new concepts at once given the entanglement
> > > > between early boot enumeration relative to memory that can optionally be
> > > > reserved from the kernel page allocator by default. The new concepts
> > > > are:
> > > >
> > > > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > > > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > > > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > > > enabled, otherwise treat it as typical ram.
> > > >
> > >
> > > OK, so now we have 'special purpose', 'specific' and 'app specific'
> > > [below]. Do they all mean the same thing?
> >
> > I struggled with separating the raw-EFI-type name from the name of the
> > Linux specific policy. Since the reservation behavior is optional I
> > was thinking there should be a distinct Linux kernel name for that
> > policy. I did try to go back and change all occurrences of "special"
> > to "specific" from the RFC to this v2, but seems I missed one.
> >
>
> OK
I'll go ahead and use "application reserved" terminology consistently
throughout the code to distinguish that Linux translation from the raw
"EFI specific purpose" attribute.
>
> > >
> > > > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > > > a device driver to search iomem resources for application specific
> > > > memory. Teach the iomem code to identify such ranges as "Application
> > > > Reserved".
> > > >
> > > > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > > > traditional System RAM pool the expectation is that they will have
> > > > typical SRAT entries. In order to support a policy of device-dax by
> > > > default with the option to hotplug later, the numa initialization code
> > > > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> > > >
> > >
> > > Can we move the generic memblock changes into a separate patch please?
> >
> > Yeah, that can move to a lead-in patch.
> >
> > [..]
> > > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > > index 91368f5ce114..b57b123cbdf9 100644
> > > > --- a/include/linux/efi.h
> > > > +++ b/include/linux/efi.h
> > > > @@ -129,6 +129,19 @@ typedef struct {
> > > > u64 attribute;
> > > > } efi_memory_desc_t;
> > > >
> > > > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > +{
> > > > + return md->type == EFI_CONVENTIONAL_MEMORY
> > > > + && (md->attribute & EFI_MEMORY_SP);
> > > > +}
> > > > +#else
> > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > > > +
> > > > typedef struct {
> > > > efi_guid_t guid;
> > > > u32 headersize;
> > >
> > > I'd prefer it if we could avoid this DAX policy distinction leaking
> > > into the EFI layer.
> > >
> > > IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
> > > whether that is DAX memory or not should be decided in the DAX layer.
> >
> > Ok, how about is_efi_sp_ram()? Since EFI_MEMORY_SP might be applied to
> > things that aren't EFI_CONVENTIONAL_MEMORY.
>
> Yes, that is fine. As long as the #ifdef lives in the DAX code and not here.
We still need some ifdef in the efi core because that is the central
location to make the policy distinction to identify identify
EFI_CONVENTIONAL_MEMORY differently depending on whether EFI_MEMORY_SP
is present. I agree with you that "dax" should be dropped from the
naming. So how about:
#ifdef CONFIG_EFI_APPLICATION_RESERVED
static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
{
return md->type == EFI_CONVENTIONAL_MEMORY
&& (md->attribute & EFI_MEMORY_SP);
}
#else
static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
{
return false;
}
#endif
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-01 4:26 ` Dan Williams
@ 2019-06-07 12:29 ` Ard Biesheuvel
2019-06-07 15:23 ` Dan Williams
0 siblings, 1 reply; 24+ messages in thread
From: Ard Biesheuvel @ 2019-06-07 12:29 UTC (permalink / raw)
To: Dan Williams
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Sat, 1 Jun 2019 at 06:26, Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Fri, May 31, 2019 at 8:30 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > On Fri, 31 May 2019 at 17:28, Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
> > > <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > (cc Mike for memblock)
> > > >
> > > > On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
> > > > >
> > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > > interpretation of the EFI Memory Types as "reserved for a special
> > > > > purpose".
> > > > >
> > > > > The proposed Linux behavior for specific purpose memory is that it is
> > > > > reserved for direct-access (device-dax) by default and not available for
> > > > > any kernel usage, not even as an OOM fallback. Later, through udev
> > > > > scripts or another init mechanism, these device-dax claimed ranges can
> > > > > be reconfigured and hot-added to the available System-RAM with a unique
> > > > > node identifier.
> > > > >
> > > > > This patch introduces 3 new concepts at once given the entanglement
> > > > > between early boot enumeration relative to memory that can optionally be
> > > > > reserved from the kernel page allocator by default. The new concepts
> > > > > are:
> > > > >
> > > > > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > > > > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > > > > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > > > > enabled, otherwise treat it as typical ram.
> > > > >
> > > >
> > > > OK, so now we have 'special purpose', 'specific' and 'app specific'
> > > > [below]. Do they all mean the same thing?
> > >
> > > I struggled with separating the raw-EFI-type name from the name of the
> > > Linux specific policy. Since the reservation behavior is optional I
> > > was thinking there should be a distinct Linux kernel name for that
> > > policy. I did try to go back and change all occurrences of "special"
> > > to "specific" from the RFC to this v2, but seems I missed one.
> > >
> >
> > OK
>
> I'll go ahead and use "application reserved" terminology consistently
> throughout the code to distinguish that Linux translation from the raw
> "EFI specific purpose" attribute.
>
OK
> >
> > > >
> > > > > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > > > > a device driver to search iomem resources for application specific
> > > > > memory. Teach the iomem code to identify such ranges as "Application
> > > > > Reserved".
> > > > >
> > > > > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > > > > traditional System RAM pool the expectation is that they will have
> > > > > typical SRAT entries. In order to support a policy of device-dax by
> > > > > default with the option to hotplug later, the numa initialization code
> > > > > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> > > > >
> > > >
> > > > Can we move the generic memblock changes into a separate patch please?
> > >
> > > Yeah, that can move to a lead-in patch.
> > >
> > > [..]
> > > > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > > > index 91368f5ce114..b57b123cbdf9 100644
> > > > > --- a/include/linux/efi.h
> > > > > +++ b/include/linux/efi.h
> > > > > @@ -129,6 +129,19 @@ typedef struct {
> > > > > u64 attribute;
> > > > > } efi_memory_desc_t;
> > > > >
> > > > > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > > +{
> > > > > + return md->type == EFI_CONVENTIONAL_MEMORY
> > > > > + && (md->attribute & EFI_MEMORY_SP);
> > > > > +}
> > > > > +#else
> > > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > > +{
> > > > > + return false;
> > > > > +}
> > > > > +#endif
> > > > > +
> > > > > typedef struct {
> > > > > efi_guid_t guid;
> > > > > u32 headersize;
> > > >
> > > > I'd prefer it if we could avoid this DAX policy distinction leaking
> > > > into the EFI layer.
> > > >
> > > > IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
> > > > whether that is DAX memory or not should be decided in the DAX layer.
> > >
> > > Ok, how about is_efi_sp_ram()? Since EFI_MEMORY_SP might be applied to
> > > things that aren't EFI_CONVENTIONAL_MEMORY.
> >
> > Yes, that is fine. As long as the #ifdef lives in the DAX code and not here.
>
> We still need some ifdef in the efi core because that is the central
> location to make the policy distinction to identify identify
> EFI_CONVENTIONAL_MEMORY differently depending on whether EFI_MEMORY_SP
> is present. I agree with you that "dax" should be dropped from the
> naming. So how about:
>
> #ifdef CONFIG_EFI_APPLICATION_RESERVED
> static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> {
> return md->type == EFI_CONVENTIONAL_MEMORY
> && (md->attribute & EFI_MEMORY_SP);
> }
> #else
> static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> {
> return false;
> }
> #endif
I think this policy decision should not live inside the EFI subsystem.
EFI just gives you the memory map, and mangling that information
depending on whether you think a certain memory attribute should be
ignored is the job of the MM subsystem.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-07 12:29 ` Ard Biesheuvel
@ 2019-06-07 15:23 ` Dan Williams
2019-06-07 17:34 ` Dan Williams
0 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-06-07 15:23 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Sat, 1 Jun 2019 at 06:26, Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, May 31, 2019 at 8:30 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Fri, 31 May 2019 at 17:28, Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > On Fri, May 31, 2019 at 1:30 AM Ard Biesheuvel
> > > > <ard.biesheuvel@linaro.org> wrote:
> > > > >
> > > > > (cc Mike for memblock)
> > > > >
> > > > > On Fri, 31 May 2019 at 01:13, Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > >
> > > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > > > > > interpretation of the EFI Memory Types as "reserved for a special
> > > > > > purpose".
> > > > > >
> > > > > > The proposed Linux behavior for specific purpose memory is that it is
> > > > > > reserved for direct-access (device-dax) by default and not available for
> > > > > > any kernel usage, not even as an OOM fallback. Later, through udev
> > > > > > scripts or another init mechanism, these device-dax claimed ranges can
> > > > > > be reconfigured and hot-added to the available System-RAM with a unique
> > > > > > node identifier.
> > > > > >
> > > > > > This patch introduces 3 new concepts at once given the entanglement
> > > > > > between early boot enumeration relative to memory that can optionally be
> > > > > > reserved from the kernel page allocator by default. The new concepts
> > > > > > are:
> > > > > >
> > > > > > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > > > > > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > > > > > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > > > > > enabled, otherwise treat it as typical ram.
> > > > > >
> > > > >
> > > > > OK, so now we have 'special purpose', 'specific' and 'app specific'
> > > > > [below]. Do they all mean the same thing?
> > > >
> > > > I struggled with separating the raw-EFI-type name from the name of the
> > > > Linux specific policy. Since the reservation behavior is optional I
> > > > was thinking there should be a distinct Linux kernel name for that
> > > > policy. I did try to go back and change all occurrences of "special"
> > > > to "specific" from the RFC to this v2, but seems I missed one.
> > > >
> > >
> > > OK
> >
> > I'll go ahead and use "application reserved" terminology consistently
> > throughout the code to distinguish that Linux translation from the raw
> > "EFI specific purpose" attribute.
> >
>
> OK
>
> > >
> > > > >
> > > > > > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > > > > > a device driver to search iomem resources for application specific
> > > > > > memory. Teach the iomem code to identify such ranges as "Application
> > > > > > Reserved".
> > > > > >
> > > > > > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > > > > > traditional System RAM pool the expectation is that they will have
> > > > > > typical SRAT entries. In order to support a policy of device-dax by
> > > > > > default with the option to hotplug later, the numa initialization code
> > > > > > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
> > > > > >
> > > > >
> > > > > Can we move the generic memblock changes into a separate patch please?
> > > >
> > > > Yeah, that can move to a lead-in patch.
> > > >
> > > > [..]
> > > > > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > > > > index 91368f5ce114..b57b123cbdf9 100644
> > > > > > --- a/include/linux/efi.h
> > > > > > +++ b/include/linux/efi.h
> > > > > > @@ -129,6 +129,19 @@ typedef struct {
> > > > > > u64 attribute;
> > > > > > } efi_memory_desc_t;
> > > > > >
> > > > > > +#ifdef CONFIG_EFI_SPECIFIC_DAX
> > > > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > > > +{
> > > > > > + return md->type == EFI_CONVENTIONAL_MEMORY
> > > > > > + && (md->attribute & EFI_MEMORY_SP);
> > > > > > +}
> > > > > > +#else
> > > > > > +static inline bool is_efi_dax(efi_memory_desc_t *md)
> > > > > > +{
> > > > > > + return false;
> > > > > > +}
> > > > > > +#endif
> > > > > > +
> > > > > > typedef struct {
> > > > > > efi_guid_t guid;
> > > > > > u32 headersize;
> > > > >
> > > > > I'd prefer it if we could avoid this DAX policy distinction leaking
> > > > > into the EFI layer.
> > > > >
> > > > > IOW, I am fine with having a 'is_efi_sp_memory()' helper here, but
> > > > > whether that is DAX memory or not should be decided in the DAX layer.
> > > >
> > > > Ok, how about is_efi_sp_ram()? Since EFI_MEMORY_SP might be applied to
> > > > things that aren't EFI_CONVENTIONAL_MEMORY.
> > >
> > > Yes, that is fine. As long as the #ifdef lives in the DAX code and not here.
> >
> > We still need some ifdef in the efi core because that is the central
> > location to make the policy distinction to identify identify
> > EFI_CONVENTIONAL_MEMORY differently depending on whether EFI_MEMORY_SP
> > is present. I agree with you that "dax" should be dropped from the
> > naming. So how about:
> >
> > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > {
> > return md->type == EFI_CONVENTIONAL_MEMORY
> > && (md->attribute & EFI_MEMORY_SP);
> > }
> > #else
> > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > {
> > return false;
> > }
> > #endif
>
> I think this policy decision should not live inside the EFI subsystem.
> EFI just gives you the memory map, and mangling that information
> depending on whether you think a certain memory attribute should be
> ignored is the job of the MM subsystem.
The problem is that we don't have an mm subsystem at the time a
decision needs to be made. The reservation policy needs to be deployed
before even memblock has been initialized in order to keep kernel
allocations out of the reservation. I agree with the sentiment I just
don't see how to practically achieve an optional "System RAM" vs
"Application Reserved" routing decision without an early (before
e820__memblock_setup()) conditional branch.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-07 15:23 ` Dan Williams
@ 2019-06-07 17:34 ` Dan Williams
2019-06-08 7:20 ` Ard Biesheuvel
0 siblings, 1 reply; 24+ messages in thread
From: Dan Williams @ 2019-06-07 17:34 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, Jun 7, 2019 at 8:23 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
[..]
> > > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > {
> > > return md->type == EFI_CONVENTIONAL_MEMORY
> > > && (md->attribute & EFI_MEMORY_SP);
> > > }
> > > #else
> > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > {
> > > return false;
> > > }
> > > #endif
> >
> > I think this policy decision should not live inside the EFI subsystem.
> > EFI just gives you the memory map, and mangling that information
> > depending on whether you think a certain memory attribute should be
> > ignored is the job of the MM subsystem.
>
> The problem is that we don't have an mm subsystem at the time a
> decision needs to be made. The reservation policy needs to be deployed
> before even memblock has been initialized in order to keep kernel
> allocations out of the reservation. I agree with the sentiment I just
> don't see how to practically achieve an optional "System RAM" vs
> "Application Reserved" routing decision without an early (before
> e820__memblock_setup()) conditional branch.
I can at least move it out of include/linux/efi.h and move it to
arch/x86/include/asm/efi.h since it is an x86 specific policy decision
/ implementation for now.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-07 17:34 ` Dan Williams
@ 2019-06-08 7:20 ` Ard Biesheuvel
2019-06-08 14:53 ` Dan Williams
2019-06-21 20:06 ` Dan Williams
0 siblings, 2 replies; 24+ messages in thread
From: Ard Biesheuvel @ 2019-06-08 7:20 UTC (permalink / raw)
To: Dan Williams
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Fri, 7 Jun 2019 at 19:34, Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Fri, Jun 7, 2019 at 8:23 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> [..]
> > > > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > {
> > > > return md->type == EFI_CONVENTIONAL_MEMORY
> > > > && (md->attribute & EFI_MEMORY_SP);
> > > > }
> > > > #else
> > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > {
> > > > return false;
> > > > }
> > > > #endif
> > >
> > > I think this policy decision should not live inside the EFI subsystem.
> > > EFI just gives you the memory map, and mangling that information
> > > depending on whether you think a certain memory attribute should be
> > > ignored is the job of the MM subsystem.
> >
> > The problem is that we don't have an mm subsystem at the time a
> > decision needs to be made. The reservation policy needs to be deployed
> > before even memblock has been initialized in order to keep kernel
> > allocations out of the reservation. I agree with the sentiment I just
> > don't see how to practically achieve an optional "System RAM" vs
> > "Application Reserved" routing decision without an early (before
> > e820__memblock_setup()) conditional branch.
>
> I can at least move it out of include/linux/efi.h and move it to
> arch/x86/include/asm/efi.h since it is an x86 specific policy decision
> / implementation for now.
No, that doesn't make sense to me. If it must live in the EFI
subsystem, I'd prefer it to be in the core code, not in x86 specific
code, since there is nothing x86 specific about it.
Perhaps a efi=xxx command line option would be in order to influence
the builtin default, but it can be a followup patch independent of
this series.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-08 7:20 ` Ard Biesheuvel
@ 2019-06-08 14:53 ` Dan Williams
2019-06-21 20:06 ` Dan Williams
1 sibling, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-06-08 14:53 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Sat, Jun 8, 2019 at 12:20 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Fri, 7 Jun 2019 at 19:34, Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, Jun 7, 2019 at 8:23 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > [..]
> > > > > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > > {
> > > > > return md->type == EFI_CONVENTIONAL_MEMORY
> > > > > && (md->attribute & EFI_MEMORY_SP);
> > > > > }
> > > > > #else
> > > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > > {
> > > > > return false;
> > > > > }
> > > > > #endif
> > > >
> > > > I think this policy decision should not live inside the EFI subsystem.
> > > > EFI just gives you the memory map, and mangling that information
> > > > depending on whether you think a certain memory attribute should be
> > > > ignored is the job of the MM subsystem.
> > >
> > > The problem is that we don't have an mm subsystem at the time a
> > > decision needs to be made. The reservation policy needs to be deployed
> > > before even memblock has been initialized in order to keep kernel
> > > allocations out of the reservation. I agree with the sentiment I just
> > > don't see how to practically achieve an optional "System RAM" vs
> > > "Application Reserved" routing decision without an early (before
> > > e820__memblock_setup()) conditional branch.
> >
> > I can at least move it out of include/linux/efi.h and move it to
> > arch/x86/include/asm/efi.h since it is an x86 specific policy decision
> > / implementation for now.
>
> No, that doesn't make sense to me. If it must live in the EFI
> subsystem, I'd prefer it to be in the core code, not in x86 specific
> code, since there is nothing x86 specific about it.
Ok, but it's still not clear to me where you would accept an early
detection of EFI_CONVENTIONAL_MEMORY + EFI_MEMORY_SP and route it away
from the "System RAM" default. Please just recommend a place to land a
conditional branch that translates between the base EFI type +
attribute and E820_RAM and E820_APPLICATION_RESERVED.
> Perhaps a efi=xxx command line option would be in order to influence
> the builtin default, but it can be a followup patch independent of
> this series.
Sure, but I expect the default polarity of the branch is a compile
time option with an efi= override.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-08 7:20 ` Ard Biesheuvel
2019-06-08 14:53 ` Dan Williams
@ 2019-06-21 20:06 ` Dan Williams
1 sibling, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-06-21 20:06 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mike Rapoport, linux-efi, the arch/x86 maintainers,
Borislav Petkov, Ingo Molnar, H. Peter Anvin, Darren Hart,
Andy Shevchenko, Thomas Gleixner, kbuild test robot,
Vishal L Verma, Linux-MM, Linux Kernel Mailing List,
linux-nvdimm
On Sat, Jun 8, 2019 at 12:20 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Fri, 7 Jun 2019 at 19:34, Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, Jun 7, 2019 at 8:23 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > [..]
> > > > > #ifdef CONFIG_EFI_APPLICATION_RESERVED
> > > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > > {
> > > > > return md->type == EFI_CONVENTIONAL_MEMORY
> > > > > && (md->attribute & EFI_MEMORY_SP);
> > > > > }
> > > > > #else
> > > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md)
> > > > > {
> > > > > return false;
> > > > > }
> > > > > #endif
> > > >
> > > > I think this policy decision should not live inside the EFI subsystem.
> > > > EFI just gives you the memory map, and mangling that information
> > > > depending on whether you think a certain memory attribute should be
> > > > ignored is the job of the MM subsystem.
> > >
> > > The problem is that we don't have an mm subsystem at the time a
> > > decision needs to be made. The reservation policy needs to be deployed
> > > before even memblock has been initialized in order to keep kernel
> > > allocations out of the reservation. I agree with the sentiment I just
> > > don't see how to practically achieve an optional "System RAM" vs
> > > "Application Reserved" routing decision without an early (before
> > > e820__memblock_setup()) conditional branch.
> >
> > I can at least move it out of include/linux/efi.h and move it to
> > arch/x86/include/asm/efi.h since it is an x86 specific policy decision
> > / implementation for now.
>
> No, that doesn't make sense to me. If it must live in the EFI
> subsystem, I'd prefer it to be in the core code, not in x86 specific
> code, since there is nothing x86 specific about it.
The decision on whether / if to take any action on this hint is
implementation specific, so I argue it does not belong in the EFI
core. The spec does not mandate any action as it's just a hint.
Instead x86 is making a policy decision in how it translates it to the
x86-specific E820 representation. So, I as I go to release v3 of this
patch set I do not see an argument to move the
is_efi_application_reserved() definition out of
arch/x86/include/asm/efi.h it's 100% tied to the e820 translation.
Now, if some other EFI supporting architecture wanted to follow the
x86 policy we could move it it to a shared location, but that's
something for a follow-on patch set.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-05-30 22:59 ` [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax Dan Williams
2019-05-31 8:29 ` Ard Biesheuvel
@ 2019-06-03 5:41 ` Mike Rapoport
2019-06-05 19:06 ` Dan Williams
1 sibling, 1 reply; 24+ messages in thread
From: Mike Rapoport @ 2019-06-03 5:41 UTC (permalink / raw)
To: Dan Williams
Cc: linux-efi, x86, Borislav Petkov, Ingo Molnar, H. Peter Anvin,
Darren Hart, Andy Shevchenko, Thomas Gleixner, Ard Biesheuvel,
kbuild test robot, vishal.l.verma, linux-mm, linux-kernel,
linux-nvdimm
Hi Dan,
On Thu, May 30, 2019 at 03:59:43PM -0700, Dan Williams wrote:
> UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> interpretation of the EFI Memory Types as "reserved for a special
> purpose".
>
> The proposed Linux behavior for specific purpose memory is that it is
> reserved for direct-access (device-dax) by default and not available for
> any kernel usage, not even as an OOM fallback. Later, through udev
> scripts or another init mechanism, these device-dax claimed ranges can
> be reconfigured and hot-added to the available System-RAM with a unique
> node identifier.
>
> This patch introduces 3 new concepts at once given the entanglement
> between early boot enumeration relative to memory that can optionally be
> reserved from the kernel page allocator by default. The new concepts
> are:
>
> - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> enabled, otherwise treat it as typical ram.
>
> - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> a device driver to search iomem resources for application specific
> memory. Teach the iomem code to identify such ranges as "Application
> Reserved".
>
> - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> traditional System RAM pool the expectation is that they will have
> typical SRAT entries. In order to support a policy of device-dax by
> default with the option to hotplug later, the numa initialization code
> is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
I'd appreciate a more elaborate description how this flag is going to be
used.
> A follow-on change integrates parsing of the ACPI HMAT to identify the
> node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> now, just identify and reserve memory of this type.
>
> Cc: <x86@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Andy Shevchenko <andy@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/x86/Kconfig | 20 ++++++++++++++++++++
> arch/x86/boot/compressed/eboot.c | 5 ++++-
> arch/x86/boot/compressed/kaslr.c | 2 +-
> arch/x86/include/asm/e820/types.h | 9 +++++++++
> arch/x86/kernel/e820.c | 9 +++++++--
> arch/x86/kernel/setup.c | 1 +
> arch/x86/platform/efi/efi.c | 37 +++++++++++++++++++++++++++++++++----
> drivers/acpi/numa.c | 15 ++++++++++++++-
> include/linux/efi.h | 14 ++++++++++++++
> include/linux/ioport.h | 1 +
> include/linux/memblock.h | 7 +++++++
> mm/memblock.c | 4 ++++
> 12 files changed, 115 insertions(+), 9 deletions(-)
...
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 08a5f4a131f5..ddde1c7b1f9a 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1109,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
>
> if (efi_enabled(EFI_MEMMAP)) {
> efi_fake_memmap();
> + efi_find_app_specific();
> efi_find_mirror();
> efi_esrt_init();
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e1cb01a22fa8..899f1305c77a 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -123,10 +123,15 @@ void __init efi_find_mirror(void)
> * more than the max 128 entries that can fit in the e820 legacy
> * (zeropage) memory map.
> */
> +enum add_efi_mode {
> + ADD_EFI_ALL,
> + ADD_EFI_APP_SPECIFIC,
> +};
>
> -static void __init do_add_efi_memmap(void)
> +static void __init do_add_efi_memmap(enum add_efi_mode mode)
> {
> efi_memory_desc_t *md;
> + int add = 0;
>
> for_each_efi_memory_desc(md) {
> unsigned long long start = md->phys_addr;
> @@ -139,7 +144,9 @@ static void __init do_add_efi_memmap(void)
> case EFI_BOOT_SERVICES_CODE:
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> - if (md->attribute & EFI_MEMORY_WB)
> + if (is_efi_dax(md))
> + e820_type = E820_TYPE_SPECIFIC;
> + else if (md->attribute & EFI_MEMORY_WB)
> e820_type = E820_TYPE_RAM;
> else
> e820_type = E820_TYPE_RESERVED;
> @@ -165,9 +172,24 @@ static void __init do_add_efi_memmap(void)
> e820_type = E820_TYPE_RESERVED;
> break;
> }
> +
> + if (e820_type == E820_TYPE_SPECIFIC) {
> + memblock_remove(start, size);
> + memblock_add_range(&memblock.reserved, start, size,
> + MAX_NUMNODES, MEMBLOCK_APP_SPECIFIC);
Why cannot this happen at e820__memblock_setup()?
Then memblock_remove() call should not be required as nothing will
memblock_add() the region.
> + } else if (mode != ADD_EFI_APP_SPECIFIC)
> + continue;
> +
> + add++;
> e820__range_add(start, size, e820_type);
> }
> - e820__update_table(e820_table);
> + if (add)
> + e820__update_table(e820_table);
> +}
> +
> +void __init efi_find_app_specific(void)
> +{
> + do_add_efi_memmap(ADD_EFI_APP_SPECIFIC);
> }
>
> int __init efi_memblock_x86_reserve_range(void)
> @@ -200,7 +222,7 @@ int __init efi_memblock_x86_reserve_range(void)
> return rv;
>
> if (add_efi_memmap)
> - do_add_efi_memmap();
> + do_add_efi_memmap(ADD_EFI_ALL);
>
> WARN(efi.memmap.desc_version != 1,
> "Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
> @@ -753,6 +775,13 @@ static bool should_map_region(efi_memory_desc_t *md)
> if (IS_ENABLED(CONFIG_X86_32))
> return false;
>
> + /*
> + * Specific purpose memory assigned to device-dax is
> + * not mapped by default.
> + */
> + if (is_efi_dax(md))
> + return false;
> +
> /*
> * Map all of RAM so that we can access arguments in the 1:1
> * mapping when making EFI runtime calls.
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index 30995834ad70..9083bb8f611b 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -260,7 +260,7 @@ void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> int __init
> acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> {
> - u64 start, end;
> + u64 start, end, i, a_start, a_end;
> u32 hotpluggable;
> int node, pxm;
>
> @@ -283,6 +283,19 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> if (acpi_srat_revision <= 1)
> pxm &= 0xff;
>
> + /* Clamp Application Specific Memory */
> + for_each_mem_range(i, &memblock.reserved, NULL, NUMA_NO_NODE,
> + MEMBLOCK_APP_SPECIFIC, &a_start, &a_end, NULL) {
> + pr_debug("%s: SP: %#llx %#llx SRAT: %#llx %#llx\n", __func__,
> + a_start, a_end, start, end);
> + if (a_start <= start && a_end >= end)
> + goto out_err;
> + if (a_start >= start && a_start < end)
> + start = a_start;
> + if (a_end <= end && end > start)
> + end = a_end;
> + }
> +
> node = acpi_map_pxm_to_node(pxm);
> if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> pr_err("SRAT: Too many proximity domains.\n");
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 91368f5ce114..b57b123cbdf9 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -129,6 +129,19 @@ typedef struct {
> u64 attribute;
> } efi_memory_desc_t;
>
> +#ifdef CONFIG_EFI_SPECIFIC_DAX
> +static inline bool is_efi_dax(efi_memory_desc_t *md)
> +{
> + return md->type == EFI_CONVENTIONAL_MEMORY
> + && (md->attribute & EFI_MEMORY_SP);
> +}
> +#else
> +static inline bool is_efi_dax(efi_memory_desc_t *md)
> +{
> + return false;
> +}
> +#endif
> +
> typedef struct {
> efi_guid_t guid;
> u32 headersize;
> @@ -1043,6 +1056,7 @@ extern efi_status_t efi_query_variable_store(u32 attributes,
> unsigned long size,
> bool nonblocking);
> extern void efi_find_mirror(void);
> +extern void efi_find_app_specific(void);
> #else
>
> static inline efi_status_t efi_query_variable_store(u32 attributes,
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index da0ebaec25f0..2d79841ee9b9 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -133,6 +133,7 @@ enum {
> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
> IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
> + IORES_DESC_APPLICATION_RESERVED = 8,
> };
>
> /* helpers to define resources */
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 676d3900e1bd..58c29180f2cd 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -35,12 +35,14 @@ extern unsigned long long max_possible_pfn;
> * @MEMBLOCK_HOTPLUG: hotpluggable region
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_APP_SPECIFIC: reserved / application specific range
> */
> enum memblock_flags {
> MEMBLOCK_NONE = 0x0, /* No special request */
> MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */
> MEMBLOCK_MIRROR = 0x2, /* mirrored region */
> MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */
> + MEMBLOCK_APP_SPECIFIC = 0x8, /* reserved / application specific range */
> };
>
> /**
> @@ -215,6 +217,11 @@ static inline bool memblock_is_mirror(struct memblock_region *m)
> return m->flags & MEMBLOCK_MIRROR;
> }
>
> +static inline bool memblock_is_app_specific(struct memblock_region *m)
> +{
> + return m->flags & MEMBLOCK_APP_SPECIFIC;
> +}
> +
> static inline bool memblock_is_nomap(struct memblock_region *m)
> {
> return m->flags & MEMBLOCK_NOMAP;
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 6bbad46f4d2c..654fecb52ba5 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -982,6 +982,10 @@ static bool should_skip_region(struct memblock_region *m, int nid, int flags)
> if ((flags & MEMBLOCK_MIRROR) && !memblock_is_mirror(m))
> return true;
>
> + /* if we want specific memory skip non-specific memory regions */
> + if ((flags & MEMBLOCK_APP_SPECIFIC) && !memblock_is_app_specific(m))
> + return true;
> +
With this the MEMBLOCK_APP_SPECIFIC won't be skipped for traversals that
don't set memblock_flags explicitly. Is this the intention?
> /* skip nomap memory unless we were asked for it explicitly */
> if (!(flags & MEMBLOCK_NOMAP) && memblock_is_nomap(m))
> return true;
>
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
2019-06-03 5:41 ` Mike Rapoport
@ 2019-06-05 19:06 ` Dan Williams
0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-06-05 19:06 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-efi, X86 ML, Borislav Petkov, Ingo Molnar, H. Peter Anvin,
Darren Hart, Andy Shevchenko, Thomas Gleixner, Ard Biesheuvel,
kbuild test robot, Vishal L Verma, Linux MM,
Linux Kernel Mailing List, linux-nvdimm
On Sun, Jun 2, 2019 at 10:42 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> Hi Dan,
>
> On Thu, May 30, 2019 at 03:59:43PM -0700, Dan Williams wrote:
> > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
> > interpretation of the EFI Memory Types as "reserved for a special
> > purpose".
> >
> > The proposed Linux behavior for specific purpose memory is that it is
> > reserved for direct-access (device-dax) by default and not available for
> > any kernel usage, not even as an OOM fallback. Later, through udev
> > scripts or another init mechanism, these device-dax claimed ranges can
> > be reconfigured and hot-added to the available System-RAM with a unique
> > node identifier.
> >
> > This patch introduces 3 new concepts at once given the entanglement
> > between early boot enumeration relative to memory that can optionally be
> > reserved from the kernel page allocator by default. The new concepts
> > are:
> >
> > - E820_TYPE_SPECIFIC: Upon detecting the EFI_MEMORY_SP attribute on
> > EFI_CONVENTIONAL memory, update the E820 map with this new type. Only
> > perform this classification if the CONFIG_EFI_SPECIFIC_DAX=y policy is
> > enabled, otherwise treat it as typical ram.
> >
> > - IORES_DESC_APPLICATION_RESERVED: Add a new I/O resource descriptor for
> > a device driver to search iomem resources for application specific
> > memory. Teach the iomem code to identify such ranges as "Application
> > Reserved".
> >
> > - MEMBLOCK_APP_SPECIFIC: Given the memory ranges can fallback to the
> > traditional System RAM pool the expectation is that they will have
> > typical SRAT entries. In order to support a policy of device-dax by
> > default with the option to hotplug later, the numa initialization code
> > is taught to avoid marking online MEMBLOCK_APP_SPECIFIC regions.
>
> I'd appreciate a more elaborate description how this flag is going to be
> used.
This flag is only there to communicate to the numa code what ranges of
"conventional memory" should be skipped for onlining and reserved for
device-dax to consume. However, now that I say that out loud I realize
I might be able to get away with just using a plain entry
memblock.reserved. I'll take a look.
>
> > A follow-on change integrates parsing of the ACPI HMAT to identify the
> > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
> > now, just identify and reserve memory of this type.
> >
> > Cc: <x86@kernel.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Darren Hart <dvhart@infradead.org>
> > Cc: Andy Shevchenko <andy@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Reported-by: kbuild test robot <lkp@intel.com>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> > arch/x86/Kconfig | 20 ++++++++++++++++++++
> > arch/x86/boot/compressed/eboot.c | 5 ++++-
> > arch/x86/boot/compressed/kaslr.c | 2 +-
> > arch/x86/include/asm/e820/types.h | 9 +++++++++
> > arch/x86/kernel/e820.c | 9 +++++++--
> > arch/x86/kernel/setup.c | 1 +
> > arch/x86/platform/efi/efi.c | 37 +++++++++++++++++++++++++++++++++----
> > drivers/acpi/numa.c | 15 ++++++++++++++-
> > include/linux/efi.h | 14 ++++++++++++++
> > include/linux/ioport.h | 1 +
> > include/linux/memblock.h | 7 +++++++
> > mm/memblock.c | 4 ++++
> > 12 files changed, 115 insertions(+), 9 deletions(-)
>
> ...
>
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 08a5f4a131f5..ddde1c7b1f9a 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1109,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
> >
> > if (efi_enabled(EFI_MEMMAP)) {
> > efi_fake_memmap();
> > + efi_find_app_specific();
> > efi_find_mirror();
> > efi_esrt_init();
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index e1cb01a22fa8..899f1305c77a 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -123,10 +123,15 @@ void __init efi_find_mirror(void)
> > * more than the max 128 entries that can fit in the e820 legacy
> > * (zeropage) memory map.
> > */
> > +enum add_efi_mode {
> > + ADD_EFI_ALL,
> > + ADD_EFI_APP_SPECIFIC,
> > +};
> >
> > -static void __init do_add_efi_memmap(void)
> > +static void __init do_add_efi_memmap(enum add_efi_mode mode)
> > {
> > efi_memory_desc_t *md;
> > + int add = 0;
> >
> > for_each_efi_memory_desc(md) {
> > unsigned long long start = md->phys_addr;
> > @@ -139,7 +144,9 @@ static void __init do_add_efi_memmap(void)
> > case EFI_BOOT_SERVICES_CODE:
> > case EFI_BOOT_SERVICES_DATA:
> > case EFI_CONVENTIONAL_MEMORY:
> > - if (md->attribute & EFI_MEMORY_WB)
> > + if (is_efi_dax(md))
> > + e820_type = E820_TYPE_SPECIFIC;
> > + else if (md->attribute & EFI_MEMORY_WB)
> > e820_type = E820_TYPE_RAM;
> > else
> > e820_type = E820_TYPE_RESERVED;
> > @@ -165,9 +172,24 @@ static void __init do_add_efi_memmap(void)
> > e820_type = E820_TYPE_RESERVED;
> > break;
> > }
> > +
> > + if (e820_type == E820_TYPE_SPECIFIC) {
> > + memblock_remove(start, size);
> > + memblock_add_range(&memblock.reserved, start, size,
> > + MAX_NUMNODES, MEMBLOCK_APP_SPECIFIC);
>
> Why cannot this happen at e820__memblock_setup()?
> Then memblock_remove() call should not be required as nothing will
> memblock_add() the region.
It's only required given the relative call order of efi_fake_memmap()
and the desire to be able to specify EFI_MEMORY_SP on the kernel
command line if the platform BIOS neglects to do it. efi_fake_memmap()
currently occurs after e820__memblock_setup() and my initial attempts
to flip the order resulted in boot failures so there is a subtle
dependency on that order I have not identified.
[..]
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 6bbad46f4d2c..654fecb52ba5 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -982,6 +982,10 @@ static bool should_skip_region(struct memblock_region *m, int nid, int flags)
> > if ((flags & MEMBLOCK_MIRROR) && !memblock_is_mirror(m))
> > return true;
> >
> > + /* if we want specific memory skip non-specific memory regions */
> > + if ((flags & MEMBLOCK_APP_SPECIFIC) && !memblock_is_app_specific(m))
> > + return true;
> > +
>
> With this the MEMBLOCK_APP_SPECIFIC won't be skipped for traversals that
> don't set memblock_flags explicitly. Is this the intention?
Yeah as per above it turns out the only real need is to identify it as
reserved, so the flag can likely go away altogether.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 5/8] lib/memregion: Uplevel the pmem "region" ida to a global allocator
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
` (3 preceding siblings ...)
2019-05-30 22:59 ` [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-30 22:59 ` [PATCH v2 6/8] device-dax: Add a driver for "hmem" devices Dan Williams
` (2 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: Keith Busch, Matthew Wilcox, vishal.l.verma, ard.biesheuvel,
linux-mm, linux-kernel, x86, linux-nvdimm
In preparation for handling platform differentiated memory types beyond
persistent memory, uplevel the "region" identifier to a global number
space. This enables a device-dax instance to be registered to any memory
type with guaranteed unique names.
Cc: Keith Busch <keith.busch@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/nvdimm/Kconfig | 1 +
drivers/nvdimm/core.c | 1 -
drivers/nvdimm/nd-core.h | 1 -
drivers/nvdimm/region_devs.c | 13 ++++---------
include/linux/memregion.h | 8 ++++++++
lib/Kconfig | 7 +++++++
lib/Makefile | 1 +
lib/memregion.c | 15 +++++++++++++++
8 files changed, 36 insertions(+), 11 deletions(-)
create mode 100644 include/linux/memregion.h
create mode 100644 lib/memregion.c
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 54500798f23a..4b3e66fe61c1 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -4,6 +4,7 @@ menuconfig LIBNVDIMM
depends on PHYS_ADDR_T_64BIT
depends on HAS_IOMEM
depends on BLK_DEV
+ select MEMREGION
help
Generic support for non-volatile memory devices including
ACPI-6-NFIT defined resources. On platforms that define an
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index acce050856a8..75fe651d327d 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -463,7 +463,6 @@ static __exit void libnvdimm_exit(void)
nd_region_exit();
nvdimm_exit();
nvdimm_bus_exit();
- nd_region_devs_exit();
nvdimm_devs_exit();
}
diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h
index e5ffd5733540..17561302dfec 100644
--- a/drivers/nvdimm/nd-core.h
+++ b/drivers/nvdimm/nd-core.h
@@ -133,7 +133,6 @@ struct nvdimm_bus *walk_to_nvdimm_bus(struct device *nd_dev);
int __init nvdimm_bus_init(void);
void nvdimm_bus_exit(void);
void nvdimm_devs_exit(void);
-void nd_region_devs_exit(void);
void nd_region_probe_success(struct nvdimm_bus *nvdimm_bus, struct device *dev);
struct nd_region;
void nd_region_create_ns_seed(struct nd_region *nd_region);
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index b4ef7d9ff22e..9e070363ff70 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -11,6 +11,7 @@
* General Public License for more details.
*/
#include <linux/scatterlist.h>
+#include <linux/memregion.h>
#include <linux/highmem.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -27,7 +28,6 @@
*/
#include <linux/io-64-nonatomic-hi-lo.h>
-static DEFINE_IDA(region_ida);
static DEFINE_PER_CPU(int, flush_idx);
static int nvdimm_map_flush(struct device *dev, struct nvdimm *nvdimm, int dimm,
@@ -141,7 +141,7 @@ static void nd_region_release(struct device *dev)
put_device(&nvdimm->dev);
}
free_percpu(nd_region->lane);
- ida_simple_remove(®ion_ida, nd_region->id);
+ memregion_free(nd_region->id);
if (is_nd_blk(dev))
kfree(to_nd_blk_region(dev));
else
@@ -1036,7 +1036,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
if (!region_buf)
return NULL;
- nd_region->id = ida_simple_get(®ion_ida, 0, 0, GFP_KERNEL);
+ nd_region->id = memregion_alloc(GFP_KERNEL);
if (nd_region->id < 0)
goto err_id;
@@ -1090,7 +1090,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
return nd_region;
err_percpu:
- ida_simple_remove(®ion_ida, nd_region->id);
+ memregion_free(nd_region->id);
err_id:
kfree(region_buf);
return NULL;
@@ -1237,8 +1237,3 @@ int nd_region_conflict(struct nd_region *nd_region, resource_size_t start,
return device_for_each_child(&nvdimm_bus->dev, &ctx, region_conflict);
}
-
-void __exit nd_region_devs_exit(void)
-{
- ida_destroy(®ion_ida);
-}
diff --git a/include/linux/memregion.h b/include/linux/memregion.h
new file mode 100644
index 000000000000..ba03c70f98d2
--- /dev/null
+++ b/include/linux/memregion.h
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef _MEMREGION_H_
+#define _MEMREGION_H_
+#include <linux/types.h>
+
+int memregion_alloc(gfp_t gfp);
+void memregion_free(int id);
+#endif /* _MEMREGION_H_ */
diff --git a/lib/Kconfig b/lib/Kconfig
index 90623a0e1942..68621a0505a6 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -335,6 +335,13 @@ config DECOMPRESS_LZ4
config GENERIC_ALLOCATOR
bool
+#
+# Memory Region ID allocation for persistent memory and "specific
+# purpose" / performance differentiated memory ranges.
+#
+config MEMREGION
+ bool
+
#
# reed solomon support is select'ed if needed
#
diff --git a/lib/Makefile b/lib/Makefile
index fb7697031a79..58cf99f68f36 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -136,6 +136,7 @@ obj-$(CONFIG_LIBCRC32C) += libcrc32c.o
obj-$(CONFIG_CRC8) += crc8.o
obj-$(CONFIG_XXHASH) += xxhash.o
obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
+obj-$(CONFIG_MEMREGION) += memregion.o
obj-$(CONFIG_842_COMPRESS) += 842/
obj-$(CONFIG_842_DECOMPRESS) += 842/
diff --git a/lib/memregion.c b/lib/memregion.c
new file mode 100644
index 000000000000..f6c6a94c7921
--- /dev/null
+++ b/lib/memregion.c
@@ -0,0 +1,15 @@
+#include <linux/idr.h>
+
+static DEFINE_IDA(region_ids);
+
+int memregion_alloc(gfp_t gfp)
+{
+ return ida_alloc(®ion_ids, gfp);
+}
+EXPORT_SYMBOL(memregion_alloc);
+
+void memregion_free(int id)
+{
+ ida_free(®ion_ids, id);
+}
+EXPORT_SYMBOL(memregion_free);
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2 6/8] device-dax: Add a driver for "hmem" devices
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
` (4 preceding siblings ...)
2019-05-30 22:59 ` [PATCH v2 5/8] lib/memregion: Uplevel the pmem "region" ida to a global allocator Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-30 22:59 ` [PATCH v2 7/8] acpi/hmat: Register HMAT at device_initcall level Dan Williams
2019-05-30 23:00 ` [PATCH v2 8/8] acpi/hmat: Register "specific purpose" memory as an "hmem" device Dan Williams
7 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: Vishal Verma, Keith Busch, Dave Jiang, kbuild test robot,
ard.biesheuvel, linux-mm, linux-kernel, x86, linux-nvdimm
Platform firmware like EFI/ACPI may publish "hmem" platform devices.
Such a device is a performance differentiated memory range likely
reserved for an application specific use case. The driver gives access
to 100% of the capacity via a device-dax mmap instance by default.
However, if over-subscription and other kernel memory management is
desired the resulting dax device can be assigned to the core-mm via the
kmem driver.
This consumes "hmem" devices the producer of "hmem" devices is saved for
a follow-on patch so that it can reference the new CONFIG_DEV_DAX_HMEM
symbol to gate performing the enumeration work.
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/dax/Kconfig | 27 +++++++++++++++++----
drivers/dax/Makefile | 2 ++
drivers/dax/hmem.c | 58 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/memregion.h | 3 ++
4 files changed, 85 insertions(+), 5 deletions(-)
create mode 100644 drivers/dax/hmem.c
diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index f33c73e4af41..9d653dfcd425 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -32,19 +32,36 @@ config DEV_DAX_PMEM
Say M if unsure
+config DEV_DAX_HMEM
+ tristate "HMEM DAX: direct access to 'specific purpose' memory"
+ depends on EFI_SPECIFIC_DAX
+ default DEV_DAX
+ help
+ EFI 2.8 platforms, and others, may advertise 'specific purpose'
+ memory. For example, a high bandwidth memory pool. The
+ indication from platform firmware is meant to reserve the
+ memory from typical usage by default. This driver creates
+ device-dax instances for these memory ranges, and that also
+ enables the possibility to assign them to the DEV_DAX_KMEM
+ driver to override the reservation and add them to kernel
+ "System RAM" pool.
+
+ Say M if unsure.
+
config DEV_DAX_KMEM
tristate "KMEM DAX: volatile-use of persistent memory"
default DEV_DAX
depends on DEV_DAX
depends on MEMORY_HOTPLUG # for add_memory() and friends
help
- Support access to persistent memory as if it were RAM. This
- allows easier use of persistent memory by unmodified
- applications.
+ Support access to persistent, or other performance
+ differentiated memory as if it were System RAM. This allows
+ easier use of persistent memory by unmodified applications, or
+ adds core kernel memory services to heterogeneous memory types
+ (HMEM) marked "reserved" by platform firmware.
To use this feature, a DAX device must be unbound from the
- device_dax driver (PMEM DAX) and bound to this kmem driver
- on each boot.
+ device_dax driver and bound to this kmem driver on each boot.
Say N if unsure.
diff --git a/drivers/dax/Makefile b/drivers/dax/Makefile
index 81f7d54dadfb..80065b38b3c4 100644
--- a/drivers/dax/Makefile
+++ b/drivers/dax/Makefile
@@ -2,9 +2,11 @@
obj-$(CONFIG_DAX) += dax.o
obj-$(CONFIG_DEV_DAX) += device_dax.o
obj-$(CONFIG_DEV_DAX_KMEM) += kmem.o
+obj-$(CONFIG_DEV_DAX_HMEM) += dax_hmem.o
dax-y := super.o
dax-y += bus.o
device_dax-y := device.o
+dax_hmem-y := hmem.o
obj-y += pmem/
diff --git a/drivers/dax/hmem.c b/drivers/dax/hmem.c
new file mode 100644
index 000000000000..741f2c222271
--- /dev/null
+++ b/drivers/dax/hmem.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/platform_device.h>
+#include <linux/memregion.h>
+#include <linux/memremap.h>
+#include <linux/module.h>
+#include <linux/pfn_t.h>
+#include "bus.h"
+
+static int dax_hmem_probe(struct platform_device *pdev)
+{
+ struct dev_pagemap pgmap = { NULL };
+ struct device *dev = &pdev->dev;
+ struct dax_region *dax_region;
+ struct memregion_info *mri;
+ struct dev_dax *dev_dax;
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOMEM;
+
+ mri = dev->platform_data;
+ pgmap.dev = dev;
+ memcpy(&pgmap.res, res, sizeof(*res));
+
+ dax_region = alloc_dax_region(dev, pdev->id, res, mri->target_node,
+ PMD_SIZE, PFN_DEV|PFN_MAP);
+ if (!dax_region)
+ return -ENOMEM;
+
+ dev_dax = devm_create_dev_dax(dax_region, 0, &pgmap);
+ if (IS_ERR(dev_dax))
+ return PTR_ERR(dev_dax);
+
+ /* child dev_dax instances now own the lifetime of the dax_region */
+ dax_region_put(dax_region);
+ return 0;
+}
+
+static int dax_hmem_remove(struct platform_device *pdev)
+{
+ /* devm handles teardown */
+ return 0;
+}
+
+static struct platform_driver dax_hmem_driver = {
+ .probe = dax_hmem_probe,
+ .remove = dax_hmem_remove,
+ .driver = {
+ .name = "hmem",
+ },
+};
+
+module_platform_driver(dax_hmem_driver);
+
+MODULE_ALIAS("platform:hmem*");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Intel Corporation");
diff --git a/include/linux/memregion.h b/include/linux/memregion.h
index ba03c70f98d2..920fb300a98b 100644
--- a/include/linux/memregion.h
+++ b/include/linux/memregion.h
@@ -3,6 +3,9 @@
#define _MEMREGION_H_
#include <linux/types.h>
+struct memregion_info {
+ int target_node;
+};
int memregion_alloc(gfp_t gfp);
void memregion_free(int id);
#endif /* _MEMREGION_H_ */
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2 7/8] acpi/hmat: Register HMAT at device_initcall level
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
` (5 preceding siblings ...)
2019-05-30 22:59 ` [PATCH v2 6/8] device-dax: Add a driver for "hmem" devices Dan Williams
@ 2019-05-30 22:59 ` Dan Williams
2019-05-30 23:00 ` [PATCH v2 8/8] acpi/hmat: Register "specific purpose" memory as an "hmem" device Dan Williams
7 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 22:59 UTC (permalink / raw)
To: linux-efi
Cc: Rafael J. Wysocki, Len Brown, Keith Busch, Jonathan Cameron,
vishal.l.verma, ard.biesheuvel, linux-mm, linux-kernel, x86,
linux-nvdimm
In preparation for registering device-dax instances for accessing EFI
specific-purpose memory, arrange for the HMAT registration to occur
later in the init process. Critically HMAT initialization needs to occur
after e820__reserve_resources_late() which is the point at which the
iomem resource tree is populated with "Application Reserved"
(IORES_DESC_APPLICATION_RESERVED). e820__reserve_resources_late()
happens at subsys_initcall time.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/acpi/hmat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/hmat.c b/drivers/acpi/hmat.c
index 2c220cb7b620..1d329c4af3bf 100644
--- a/drivers/acpi/hmat.c
+++ b/drivers/acpi/hmat.c
@@ -671,4 +671,4 @@ static __init int hmat_init(void)
acpi_put_table(tbl);
return 0;
}
-subsys_initcall(hmat_init);
+device_initcall(hmat_init);
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2 8/8] acpi/hmat: Register "specific purpose" memory as an "hmem" device
2019-05-30 22:59 [PATCH v2 0/8] EFI Specific Purpose Memory Support Dan Williams
` (6 preceding siblings ...)
2019-05-30 22:59 ` [PATCH v2 7/8] acpi/hmat: Register HMAT at device_initcall level Dan Williams
@ 2019-05-30 23:00 ` Dan Williams
7 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2019-05-30 23:00 UTC (permalink / raw)
To: linux-efi
Cc: Len Brown, Keith Busch, Rafael J. Wysocki, Vishal Verma,
Jonathan Cameron, ard.biesheuvel, linux-mm, linux-kernel, x86,
linux-nvdimm
Memory that has been tagged EFI_MEMORY_SP, and has performance
properties described by the ACPI HMAT is expected to have an application
specific consumer.
Those consumers may want 100% of the memory capacity to be reserved from
any usage by the kernel. By default, with this enabling, a platform
device is created to represent this differentiated resource.
The device-dax "hmem" driver claims these devices by default and
provides an mmap interface for the target application. If the
administrator prefers, the hmem resource range can be made available to
the core-mm via the device-dax hotplug facility, kmem, to online the
memory with its own numa node.
This was tested with an emulated HMAT produced by qemu (with the pending
HMAT enabling patches), and "efi_fake_mem=8G@9G:0x40000" on the kernel
command line to mark the memory ranges associated with node2 and node3
as EFI_MEMORY_SP.
qemu numa configuration options:
-numa node,mem=4G,cpus=0-19,nodeid=0
-numa node,mem=4G,cpus=20-39,nodeid=1
-numa node,mem=4G,nodeid=2
-numa node,mem=4G,nodeid=3
-numa dist,src=0,dst=0,val=10
-numa dist,src=0,dst=1,val=21
-numa dist,src=0,dst=2,val=21
-numa dist,src=0,dst=3,val=21
-numa dist,src=1,dst=0,val=21
-numa dist,src=1,dst=1,val=10
-numa dist,src=1,dst=2,val=21
-numa dist,src=1,dst=3,val=21
-numa dist,src=2,dst=0,val=21
-numa dist,src=2,dst=1,val=21
-numa dist,src=2,dst=2,val=10
-numa dist,src=2,dst=3,val=21
-numa dist,src=3,dst=0,val=21
-numa dist,src=3,dst=1,val=21
-numa dist,src=3,dst=2,val=21
-numa dist,src=3,dst=3,val=10
-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,base-lat=10,latency=5
-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=5
-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,base-lat=10,latency=10
-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=10
-numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-latency,base-lat=10,latency=15
-numa hmat-lb,initiator=0,target=2,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=15
-numa hmat-lb,initiator=0,target=3,hierarchy=memory,data-type=access-latency,base-lat=10,latency=20
-numa hmat-lb,initiator=0,target=3,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=20
-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,base-lat=10,latency=10
-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=10
-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,base-lat=10,latency=5
-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=5
-numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-latency,base-lat=10,latency=15
-numa hmat-lb,initiator=1,target=2,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=15
-numa hmat-lb,initiator=1,target=3,hierarchy=memory,data-type=access-latency,base-lat=10,latency=20
-numa hmat-lb,initiator=1,target=3,hierarchy=memory,data-type=access-bandwidth,base-bw=20,bandwidth=20
Result:
# daxctl list -RDu
[
{
"path":"\/platform\/hmem.1",
"id":1,
"size":"4.00 GiB (4.29 GB)",
"align":2097152,
"devices":[
{
"chardev":"dax1.0",
"size":"4.00 GiB (4.29 GB)"
}
]
},
{
"path":"\/platform\/hmem.0",
"id":0,
"size":"4.00 GiB (4.29 GB)",
"align":2097152,
"devices":[
{
"chardev":"dax0.0",
"size":"4.00 GiB (4.29 GB)"
}
]
}
]
# cat /proc/iomem
[..]
240000000-43fffffff : Application Reserved
240000000-33fffffff : hmem.0
240000000-33fffffff : dax0.0
340000000-43fffffff : hmem.1
340000000-43fffffff : dax1.0
Cc: Len Brown <lenb@kernel.org>
Cc: Keith Busch <keith.busch@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/acpi/Kconfig | 1
drivers/acpi/hmat.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 123 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ec8691e4152f..a4e67b7dcc9d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -480,6 +480,7 @@ config ACPI_HMAT
bool "ACPI Heterogeneous Memory Attribute Table Support"
depends on ACPI_NUMA
select HMEM_REPORTING
+ select MEMREGION
help
If set, this option has the kernel parse and report the
platform's ACPI HMAT (Heterogeneous Memory Attributes Table),
diff --git a/drivers/acpi/hmat.c b/drivers/acpi/hmat.c
index 1d329c4af3bf..5c714e6e5293 100644
--- a/drivers/acpi/hmat.c
+++ b/drivers/acpi/hmat.c
@@ -8,11 +8,17 @@
* the applicable attributes with the node's interfaces.
*/
+#define pr_fmt(fmt) "acpi/hmat: " fmt
+#define dev_fmt(fmt) "acpi/hmat: " fmt
+
#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/memregion.h>
+#include <linux/platform_device.h>
#include <linux/list_sort.h>
#include <linux/node.h>
#include <linux/sysfs.h>
@@ -40,6 +46,7 @@ struct memory_target {
struct list_head node;
unsigned int memory_pxm;
unsigned int processor_pxm;
+ struct resource memregions;
struct node_hmem_attrs hmem_attrs;
};
@@ -92,21 +99,35 @@ static __init void alloc_memory_initiator(unsigned int cpu_pxm)
list_add_tail(&initiator->node, &initiators);
}
-static __init void alloc_memory_target(unsigned int mem_pxm)
+static __init void alloc_memory_target(unsigned int mem_pxm,
+ resource_size_t start, resource_size_t len)
{
struct memory_target *target;
target = find_mem_target(mem_pxm);
- if (target)
- return;
-
- target = kzalloc(sizeof(*target), GFP_KERNEL);
- if (!target)
- return;
+ if (!target) {
+ target = kzalloc(sizeof(*target), GFP_KERNEL);
+ if (!target)
+ return;
+ target->memory_pxm = mem_pxm;
+ target->processor_pxm = PXM_INVAL;
+ target->memregions = (struct resource) {
+ .name = "ACPI mem",
+ .start = 0,
+ .end = -1,
+ .flags = IORESOURCE_MEM,
+ };
+ list_add_tail(&target->node, &targets);
+ }
- target->memory_pxm = mem_pxm;
- target->processor_pxm = PXM_INVAL;
- list_add_tail(&target->node, &targets);
+ /*
+ * There are potentially multiple ranges per PXM, so record each
+ * in the per-target memregions resource tree.
+ */
+ if (!__request_region(&target->memregions, start, len, "memory target",
+ IORESOURCE_MEM))
+ pr_warn("failed to reserve %#llx - %#llx in pxm: %d\n",
+ start, start + len, mem_pxm);
}
static __init const char *hmat_data_type(u8 type)
@@ -428,7 +449,7 @@ static __init int srat_parse_mem_affinity(union acpi_subtable_headers *header,
return -EINVAL;
if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
return 0;
- alloc_memory_target(ma->proximity_domain);
+ alloc_memory_target(ma->proximity_domain, ma->base_address, ma->length);
return 0;
}
@@ -580,6 +601,81 @@ static __init void hmat_register_target_perf(struct memory_target *target)
node_set_perf_attrs(mem_nid, &target->hmem_attrs, 0);
}
+static __init void hmat_register_target_device(struct memory_target *target,
+ struct resource *r)
+{
+ /* define a clean / non-busy resource for the platform device */
+ struct resource res = {
+ .start = r->start,
+ .end = r->end,
+ .flags = IORESOURCE_MEM,
+ };
+ struct platform_device *pdev;
+ struct memregion_info info;
+ int rc, id;
+
+ rc = region_intersects(res.start, resource_size(&res), IORESOURCE_MEM,
+ IORES_DESC_APPLICATION_RESERVED);
+ if (rc != REGION_INTERSECTS)
+ return;
+
+ id = memregion_alloc(GFP_KERNEL);
+ if (id < 0) {
+ pr_err("memregion allocation failure for %pr\n", &res);
+ return;
+ }
+
+ pdev = platform_device_alloc("hmem", id);
+ if (!pdev) {
+ pr_err("hmem device allocation failure for %pr\n", &res);
+ goto out_pdev;
+ }
+
+ pdev->dev.numa_node = acpi_map_pxm_to_online_node(target->memory_pxm);
+ info = (struct memregion_info) {
+ .target_node = acpi_map_pxm_to_node(target->memory_pxm),
+ };
+ rc = platform_device_add_data(pdev, &info, sizeof(info));
+ if (rc < 0) {
+ pr_err("hmem memregion_info allocation failure for %pr\n", &res);
+ goto out_pdev;
+ }
+
+ rc = platform_device_add_resources(pdev, &res, 1);
+ if (rc < 0) {
+ pr_err("hmem resource allocation failure for %pr\n", &res);
+ goto out_resource;
+ }
+
+ rc = platform_device_add(pdev);
+ if (rc < 0) {
+ dev_err(&pdev->dev, "device add failed for %pr\n", &res);
+ goto out_resource;
+ }
+
+ return;
+
+out_resource:
+ put_device(&pdev->dev);
+out_pdev:
+ memregion_free(id);
+}
+
+static __init void hmat_register_target_devices(struct memory_target *target)
+{
+ struct resource *res;
+
+ /*
+ * Do not bother creating devices if no driver is available to
+ * consume them.
+ */
+ if (!IS_ENABLED(CONFIG_DEV_DAX_HMEM))
+ return;
+
+ for (res = target->memregions.child; res; res = res->sibling)
+ hmat_register_target_device(target, res);
+}
+
static __init void hmat_register_targets(void)
{
struct memory_target *target;
@@ -587,6 +683,12 @@ static __init void hmat_register_targets(void)
list_for_each_entry(target, &targets, node) {
int nid = pxm_to_node(target->memory_pxm);
+ /*
+ * Devices may belong to either an offline or online
+ * node, so unconditionally add them.
+ */
+ hmat_register_target_devices(target);
+
/*
* Skip offline nodes. This can happen when memory
* marked EFI_MEMORY_SP, "specific purpose", is applied
@@ -608,7 +710,16 @@ static __init void hmat_free_structures(void)
struct memory_initiator *initiator, *inext;
list_for_each_entry_safe(target, tnext, &targets, node) {
+ struct resource *res, *res_next;
+
list_del(&target->node);
+ res = target->memregions.child;
+ while (res) {
+ res_next = res->sibling;
+ __release_region(&target->memregions, res->start,
+ resource_size(res));
+ res = res_next;
+ }
kfree(target);
}
^ permalink raw reply related [flat|nested] 24+ messages in thread