From: Ingo Molnar <mingo@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: tglx@linutronix.de, rafael.j.wysocki@intel.com, x86@kernel.org,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
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
Subject: Re: [PATCH v5 05/10] x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP
Date: Tue, 10 Sep 2019 08:48:26 +0200 [thread overview]
Message-ID: <20190910064826.GA23659@gmail.com> (raw)
In-Reply-To: <156712996407.1616117.11409311856083390862.stgit@dwillia2-desk3.amr.corp.intel.com>
* Dan Williams <dan.j.williams@intel.com> wrote:
> Given that EFI_MEMORY_SP is platform BIOS policy descision for marking
> memory ranges as "reserved for a specific purpose" there will inevitably
> be scenarios where the BIOS omits the attribute in situations where it
> is desired. Unlike other attributes if the OS wants to reserve this
> memory from the kernel the reservation needs to happen early in init. So
> early, in fact, that it needs to happen before e820__memblock_setup()
> which is a pre-requisite for efi_fake_memmap() that wants to allocate
> memory for the updated table.
>
> Introduce an x86 specific efi_fake_memmap_early() that can search for
> attempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 table
> accordingly.
>
> The KASLR code that scans the command line looking for user-directed
> memory reservations also needs to be updated to consider
> "efi_fake_mem=nn@ss:0x40000" requests.
>
> Cc: <x86@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: 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>
A couple of these patches are touching EFI code, but only the first one
carries a Reviewed-by from Ard.
Ard, are these patches and the whole series fine with you?
Thanks,
Ingo
next prev parent reply other threads:[~2019-09-10 6:48 UTC|newest]
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 ` [PATCH v5 02/10] efi: Enumerate EFI_MEMORY_SP Dan Williams
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 [this message]
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 publicly 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=20190910064826.GA23659@gmail.com \
--to=mingo@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.