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

[Breno Leitao]

Hello Ard,

Thanks for the feedback!

On Wed, Sep 09, 2026 at 04:47:27PM +0200, Ard Biesheuvel wrote:
> On Wed, 9 Sep 2026, at 15:05, Breno Leitao wrote:
> > A EFI config table can only be installed while boot services are still
> > up, so the stub has to create it; the running kernel can only flip bits
> > in a table that already exists.
>
> This is true, but that also means a config table could have a 'next' field
> pointing to an allocation that was added later.
>
> There is a EFI memreserve table based on this principle: this is a hack
> that we added for the arm64 GICv3 LPI table handling, which is a braindead
> piece of kit that must use the same physical allocation as the previous
> kernel. It is not currently enabled on x86.
>
> Please consider whether or not that is more suitable, and can be repurposed
> or shared. (Feel free to make changes to the current format if needed).

That's actually what I tried in the RFC. I passed an almost-empty EFI
table, then built a linked list of poisoned pages on top of it.

It looked like this:

	struct linux_efi_poisoned_memory {
		int		size;			// allocated size of the array
		atomic_t	count;			// number of entries used
		phys_addr_t	next;			// pa of next struct instance
		struct {
			phys_addr_t	base;
			phys_addr_t	size;
		} entry[];
	};


The allocation walks that list the same way; see
efi_hwpoison_record_pfn() in patch "[PATCH RFC 2/3] efi: record hardware-poisoned frames into the poisoned-memory table"

This is the RFC patchset:
https://lore.kernel.org/all/20260717-hwpoison-kho-v1-1-9c5eda551998@xxxxxxxxxx/#t

> I don't have a strong preference either way, but I feel the 2M granularity
> may be a bit wasteful, no?

Maybe. It's the same trade-off as unaccepted memory: reducing the
granularity means growing the bitmap.

We can reduce the granularity, but I don't think we should reduce the
granularity if we're going to KEEP using a bitmap.

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?
--breno