Re: [PATCH v2 2/6] efi: add the LINUX_EFI_POISONED_MEMORY configuration table

[Breno Leitao <leitao@debian.org>]

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?