Re: [PATCH v4 2/5] mm/memory-failure: libstub: install the poisoned-memory EFI table

[Breno Leitao <leitao@debian.org>]

Hi Harry,

Thanks a lot for the feedback.

On Tue, Sep 15, 2026 at 01:12:54PM +0100, Harry Yoo wrote:
> On Tue, Sep 15, 2026 at 02:03:48AM -0700, Breno Leitao wrote:
> > On Thu, Sep 10, 2026 at 06:11:53AM -0700, Breno Leitao wrote:
> > > So I'd say we have two options:
> > >
> > > 1) Keep it similar to unaccepted memory, with 2M granularity.
> > >    - Pro : Similar mental model as unnacepted memory
> > >    - Cons: 2 MB might be a bit wasteful
> > >
> > > 2) Move to a linked list like the RFC, keeping it outside of the EFI
> > >    table.
> > >    - Pro: Reduce the memory granularities to page instead of 2M blocs.
> > >    - Cons: Another way of passing memory information between kexec
> > >      kernels.
> > >
> > > Any any other option or strong preference?
> >
> > Since nobody voiced a strong preference, I will stick with option (1),
> > the bitmap, for these reasons:
>
> Not sure if this was discussed already, but perhaps we need to have
> a chain of struct linux_efi_poisoned_memory rather than a single
> bitmap, to easily add support for hot-added memory later?

Agreed, that's a good point. We could extend linux_efi_poisoned_memory
with a ->next pointer, so that if we ever add hot-plug support later, we
can link in another linux_efi_poisoned_memory. 

That said, I'm not sure hot-plug memory is really relevant here. Hot-plug
is mostly used in VMs, while this feature is more host-side, so it doesn't
seem like a great fit. Maybe it would only matter for servers where
physical memory can be added while running (do those still exist? I
recall IBM offered that feature at some point, but I'm not sure there are
real customers for it).

> Also, I wonder if some architectures have a scattered set of pfn
> ranges so that the span from the start pfn to the end pfn being much
> larger than the actual physical memory size.
>
> If so it might make more sense to have a bitmap for each pfn range.

Agreed, having a ->next in linux_efi_poisoned_memory is a good idea that
we can lean on depending on whatever problem comes up down the road.

Very good point — let's keep this linux_efi_poisoned_memory chain idea in
mind for whenever we need to expand it.