Re: [PATCH v2 2/6] efi: add the LINUX_EFI_POISONED_MEMORY configuration table
Breno Leitao <[email protected]>
| Newsgroups | org.kernel.vger.linux-efi,org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 21, 2026 at 12:51:34PM +0100, Kiryl Shutsemau wrote: > On Fri, Aug 21, 2026 at 03:06:02AM -0700, Breno Leitao wrote: > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > > index 29e0729299f5b..69c0dc02bc112 100644 > > --- a/drivers/firmware/efi/Kconfig > > +++ b/drivers/firmware/efi/Kconfig > > @@ -263,6 +263,16 @@ config EFI_COCO_SECRET > > virt/coco/efi_secret module to access the secrets, which in turn > > allows userspace programs to access the injected secrets. > > > > +config EFI_POISONED_MEMORY > > + bool "Carry hardware-poisoned pages across kexec" > > + depends on EFI_STUB && MEMORY_FAILURE && 64BIT > > + help > > + Record page frames that are hardware-poisoned while this kernel runs > > + into an EFI configuration table, and honor that table early on the > > + next kernel so a kexec does not hand known-bad RAM back out. > > + > > + If unsure, say N. > > + > > Do we want to make it conditional? Maybe just for everyone with EFI_STUB > && MEMORY_FAILURE? > > Where 64BIT limitation comes from? That simplifies a bit the maths for memory operations, and make them more digestible. Do we really care about it on non 64 bits platform?