Linux-EFI Archive on lore.kernel.org
 help / color / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: tglx@linutronix.de, rafael.j.wysocki@intel.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	peterz@infradead.org, vishal.l.verma@intel.com,
	linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	x86@kernel.org
Subject: [PATCH v5 02/10] efi: Enumerate EFI_MEMORY_SP
Date: Thu, 29 Aug 2019 18:52:28 -0700
Message-ID: <156712994859.1616117.15085206590367158743.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)
In-Reply-To: <156712993795.1616117.3781864460118989466.stgit@dwillia2-desk3.amr.corp.intel.com>

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
(soft reserved) 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. This reservation hint
allows platform-firmware to instead tell the truth about performance
characteristics by indicate to OS memory management to put immovable
allocations elsewhere.

Implement simple detection of the bit for EFI memory table dumps and
save the kernel policy for a follow-on change.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
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 8f1ab04f6743..363bb9d00fa5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -833,15 +833,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 bd3837022307..5c1dd0221384 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)	/* soft reserved */
 #define EFI_MEMORY_RUNTIME	((u64)0x8000000000000000ULL)	/* range requires runtime mapping */
 #define EFI_MEMORY_DESCRIPTOR_VERSION	1
 


  parent reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30  1:52 [PATCH v5 00/10] EFI Specific Purpose Memory Support Dan Williams
2019-08-30  1:52 ` [PATCH v5 01/10] acpi/numa: Establish a new drivers/acpi/numa/ directory Dan Williams
2019-08-30  1:52 ` Dan Williams [this message]
2019-08-30  1:52 ` [PATCH v5 03/10] x86, efi: Push EFI_MEMMAP check into leaf routines Dan Williams
2019-09-13  9:05   ` Ard Biesheuvel
2019-09-13 12:32     ` Dan Williams
2019-08-30  1:52 ` [PATCH v5 04/10] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax Dan Williams
2019-09-13 12:59   ` Ard Biesheuvel
2019-09-13 16:22     ` Dan Williams
2019-09-13 16:28       ` Ard Biesheuvel
2019-09-13 16:39         ` Dan Williams
2019-09-13 17:39           ` Ard Biesheuvel
2019-09-13 17:54             ` Ard Biesheuvel
2019-08-30  1:52 ` [PATCH v5 05/10] x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP Dan Williams
2019-09-10  6:48   ` Ingo Molnar
2019-09-13 13:02   ` Ard Biesheuvel
2019-09-13 15:02     ` Dan Williams
2019-09-13 19:48   ` Ard Biesheuvel
2019-09-13 20:43     ` Dan Williams
2019-08-30  1:52 ` [PATCH v5 06/10] lib: Uplevel the pmem "region" ida to a global allocator Dan Williams
2019-08-30  1:52 ` [PATCH v5 07/10] dax: Fix alloc_dax_region() compile warning Dan Williams
2019-08-30  1:53 ` [PATCH v5 08/10] device-dax: Add a driver for "hmem" devices Dan Williams
2019-08-30  1:53 ` [PATCH v5 09/10] acpi/numa/hmat: Register HMAT at device_initcall level Dan Williams
2019-08-30  1:53 ` [PATCH v5 10/10] acpi/numa/hmat: Register "soft reserved" memory as an "hmem" device Dan Williams
2019-09-02 11:09 ` [PATCH v5 00/10] EFI Specific Purpose Memory Support Rafael J. Wysocki
2019-09-04 23:06   ` Dan Williams
2019-09-06 11:37     ` Rafael J. Wysocki
2019-10-03 15:43       ` Jonathan Cameron

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=156712994859.1616117.15085206590367158743.stgit@dwillia2-desk3.amr.corp.intel.com \
    --to=dan.j.williams@intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vishal.l.verma@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-EFI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-efi/0 linux-efi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-efi linux-efi/ https://lore.kernel.org/linux-efi \
		linux-efi@vger.kernel.org linux-efi@archiver.kernel.org
	public-inbox-index linux-efi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-efi


AGPL code for this site: git clone https://public-inbox.org/ public-inbox