Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	kbuild test robot <lkp@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration
Date: Fri, 11 Oct 2019 16:38:05 +0200
Message-ID: <CAKv+Gu-Y+0KjUj91N1WFZK=vR6CUKCtiNbQtYMxn2vY1Wh-_dg@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4jHTrrfNnBNw_H_4wGWGsg1QF1582BcN-078K5KCBhNBA@mail.gmail.com>

On Fri, 11 Oct 2019 at 16:35, Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Thu, Oct 10, 2019 at 10:52 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > On Fri, 11 Oct 2019 at 04:39, Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel
> > > <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > On Thu, 10 Oct 2019 at 20:31, Dan Williams <dan.j.williams@intel.com> wrote:
> > > > >
> > > > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel
> > > > > <ard.biesheuvel@linaro.org> wrote:
> > > > > >
> > > > > > On Thu, 10 Oct 2019 at 01:19, 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 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 device-dax management scheme implements "soft" in
> > > > > > > the "soft reserved" designation by allowing some or all of the
> > > > > > > reservation to be recovered as typical memory. This policy can be
> > > > > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
> > > > > > > efi=nosoftreserve.
> > > > > > >
> > > > > > > This patch introduces 2 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_SOFT_RESERVED: 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_SOFT_RESERVE=y policy is enabled, otherwise treat it as
> > > > > > >   typical ram.
> > > > > > >
> > > > > > > - IORES_DESC_SOFT_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 "Soft Reserved".
> > > > > > >
> > > > > > > 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: Andy Lutomirski <luto@kernel.org>
> > > > > > > Cc: Peter Zijlstra <peterz@infradead.org>
> > > > > > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > > > > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > > > > Reported-by: kbuild test robot <lkp@intel.com>
> > > > > > > Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> > > > > > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > > > > >
> > > > > > For the EFI changes
> > > > > >
> > > > > > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > > >
> > > > > > although I must admit I don't follow the enum add_efi_mode logic 100%
> > > > >
> > > > > I'm open to suggestions as I'm not sure it's the best possible
> > > > > organization. The do_add_efi_memmap() routine has the logic to
> > > > > translate EFI to E820, but unless "add_efi_memmap" is specified on the
> > > > > kernel command line the EFI memory map is ignored. For
> > > > > soft-reservation support I want to reuse do_add_efi_memmap(), but
> > > > > otherwise avoid any other side effects of considering the EFI map.
> > > > > What I'm missing is the rationale for why "add_efi_memmap" is required
> > > > > before considering the EFI memory map.
> > > > >
> > > > > If there is a negative side effect to always using the EFI map then
> > > > > the new "add_efi_mode" designation constrains it to just the
> > > > > soft-reservation case.
> > > > >
> > > >
> > > > Could we make the presence of any EFI_MEMORY_SP regions imply
> > > > add_efi_memmap? That way, it is guaranteed that we don't regress
> > > > existing systems, while establishing clear and unambiguous semantics
> > > > for new systems that rely on these changes in order to be able to use
> > > > the special purpose memory as intended.
> > >
> > > In fact that's how it works. EFI_MEMORY_SP is unconditionally added.
> > > Other EFI memory types are optionally added with the add_efi_memmap
> > > option.
> >
> > That is not what I meant.
> >
> > Why not behave as if 'add_efi_memmap' was passed if any EFI_MEMORY_SP
> > regions exist?
>
> Hmm, ok, on the assumption that any platform that is modern enough to
> specify EFI_MEMORY_SP likely does not need the opt-in?

Indeed.

> I can get on
> board with that. It's also simple enough to undo if it causes problems
> in practice.

Yes, and we'll only have one code path to reason about here.

  reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 23:04 [PATCH v6 00/12] EFI Specific Purpose Memory Support Dan Williams
2019-10-09 23:04 ` [PATCH v6 01/12] acpi/numa: Establish a new drivers/acpi/numa/ directory Dan Williams
2019-10-09 23:04 ` [PATCH v6 02/12] efi: Enumerate EFI_MEMORY_SP Dan Williams
2019-10-09 23:04 ` [PATCH v6 03/12] x86/efi: Push EFI_MEMMAP check into leaf routines Dan Williams
2019-10-09 23:04 ` [PATCH v6 04/12] efi: Common enable/disable infrastructure for EFI soft reservation Dan Williams
2019-10-10  6:36   ` Ard Biesheuvel
2019-10-09 23:05 ` [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration Dan Williams
2019-10-10  6:44   ` Ard Biesheuvel
2019-10-10 18:31     ` Dan Williams
2019-10-10 18:40       ` Ard Biesheuvel
2019-10-11  2:39         ` Dan Williams
2019-10-11  5:52           ` Ard Biesheuvel
2019-10-11 14:35             ` Dan Williams
2019-10-11 14:38               ` Ard Biesheuvel [this message]
2019-10-09 23:05 ` [PATCH v6 06/12] arm/efi: EFI soft reservation to memblock Dan Williams
2019-10-10  6:46   ` Ard Biesheuvel
2019-10-09 23:05 ` [PATCH v6 07/12] x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP Dan Williams
2019-10-10  7:01   ` Ard Biesheuvel
2019-10-09 23:05 ` [PATCH v6 08/12] lib: Uplevel the pmem "region" ida to a global allocator Dan Williams
2019-10-09 23:05 ` [PATCH v6 09/12] dax: Fix alloc_dax_region() compile warning Dan Williams
2019-10-09 23:05 ` [PATCH v6 10/12] device-dax: Add a driver for "hmem" devices Dan Williams
2019-10-09 23:05 ` [PATCH v6 11/12] acpi/numa/hmat: Register HMAT at device_initcall level Dan Williams
2019-10-09 23:05 ` [PATCH v6 12/12] acpi/numa/hmat: Register "soft reserved" memory as an "hmem" device Dan Williams

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='CAKv+Gu-Y+0KjUj91N1WFZK=vR6CUKCtiNbQtYMxn2vY1Wh-_dg@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=andy@infradead.org \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/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-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

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


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