Messages in this thread | | | From | Dan Williams <> | Date | Fri, 7 Jun 2019 10:34:36 -0700 | Subject | Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax |
| |
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.
| |