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.
