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
