On Tue, Sep 15, 2026 at 06:38:47AM -0700, Breno Leitao wrote: > 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.
Ack. > 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? That will work, no strong opinion here. -- Cheers, Harry / Hyeonggon
