From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>,
linux-efi <linux-efi@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
kbuild test robot <lkp@intel.com>,
Vishal L Verma <vishal.l.verma@intel.com>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
Date: Sat, 8 Jun 2019 09:20:13 +0200 [thread overview]
Message-ID: <CAKv+Gu_OcsWi5DqxOk-j6ovc0CMAZV37Od7zA5Bs4Ng5ATQxAA@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4gzhr57xa2MbR1Jk8EDFw-WLdcw3mJnEX9PeAFwVEZbDA@mail.gmail.com>
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.
next prev parent reply other threads:[~2019-06-08 7:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
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-31 8:23 ` Rafael J. Wysocki
2019-05-31 14:52 ` 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 ` [PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP 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
2019-05-31 8:29 ` Ard Biesheuvel
2019-05-31 15:28 ` Dan Williams
2019-05-31 15:30 ` Ard Biesheuvel
2019-06-01 4:26 ` Dan Williams
2019-06-07 12:29 ` Ard Biesheuvel
2019-06-07 15:23 ` Dan Williams
2019-06-07 17:34 ` Dan Williams
2019-06-08 7:20 ` Ard Biesheuvel [this message]
2019-06-08 14:53 ` Dan Williams
2019-06-21 20:06 ` Dan Williams
2019-06-03 5:41 ` Mike Rapoport
2019-06-05 19:06 ` Dan Williams
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 ` [PATCH v2 6/8] device-dax: Add a driver for "hmem" devices 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
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=CAKv+Gu_OcsWi5DqxOk-j6ovc0CMAZV37Od7zA5Bs4Ng5ATQxAA@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=andy@infradead.org \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=lkp@intel.com \
--cc=mingo@redhat.com \
--cc=rppt@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox