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

[Harry Yoo <harry@kernel.org>]

On Tue, Sep 15, 2026 at 05:39:44AM -0700, Breno Leitao wrote:
> Hi Harry,
> 
> Thanks a lot for the feedback.

Hi Breno, no problem!

> 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).

IIRC CXL memory modules can be set up either by firmware or hot-plugged
after boot. Not sure how common the latter case is (or will be) in
practice, though.

> > 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.

You mean 1) keeping the structure as-is for now (and expand later with
new EFI table version) or 2) adjusting the structure in the future
revision of this patchset?

-- 
Cheers,
Harry / Hyeonggon