On Tue, Sep 15, 2026 at 02:31:38PM +0100, Harry Yoo wrote: > On Tue, Sep 15, 2026 at 05:39:44AM -0700, Breno Leitao wrote: > > > 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?
I'd say option (1): keep the structure as it is for now, and only adjust it once/if we actually decide to implement the hot-add use case. That's exactly why I added the "u32 version" field to struct linux_efi_poisoned_memory, so, it can be expanded later. Version 1 (this patchset) covers the common, basic approach. If down the road someone sees value in extending it to other use cases (such as hot-plug), we can bump it to v2 and add a ->next field then. What do you think? Thanks for the review, --breno
