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/[email protected]/#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
