From: Breno Leitao <leitao@debian.org>
To: Kiryl Shutsemau <kas@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
kexec@lists.infradead.org, David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, rmikey@meta.com, riel@surriel.com,
kernel-team@meta.com
Subject: Re: [PATCH v3 2/5] mm/memory-failure: libstub: install the poisoned-memory EFI table
Date: Mon, 7 Sep 2026 07:47:41 -0700 [thread overview]
Message-ID: <ap7OBwOs8BKGUJh8@gmail.com> (raw)
In-Reply-To: <apGSy78NoCov0MWr@thinkstation>
On Fri, Aug 28, 2026 at 02:59:43PM +0100, Kiryl Shutsemau wrote:
> On Wed, Aug 26, 2026 at 05:03:53AM -0700, 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.
> >
> > Size the bitmap from the top of usable RAM, which efi_get_ram_top()
> > works out by walking the UEFI memory map, since the stub has no max_pfn.
> > Bit N covers unit N counting from address 0, so the table tracks
> > max_pfn. Memory the firmware hot-adds later sits above it and is not
> > carried across a kexec.
> >
> > One table has to serve every architecture, so efi_get_ram_top() takes
> > the union of the memory types they turn into RAM: what setup_e820() maps
> > to E820_TYPE_RAM on x86, plus the EFI_ACPI_RECLAIM_MEMORY and
> > EFI_PERSISTENT_MEMORY that is_usable_memory() accepts on arm64. Sizing
> > wide only costs bitmap bytes; sizing narrow silently drops the records
> > for every frame above the top.
>
> x86 and ARM doesn't seem to agree what RAM is. On x86 it is by ->type
> and on ARM it is by ->attribute (anything WB/WC/WT).
>
> is_usable_memory() only decides nomap. Everything is_memory() lets in
> lands in memblock.memory, and max_pfn is PFN_DOWN(memblock_end_of_DRAM()),
> so the top of RAM there can be a type that is not on your list.
Thanks. I will just ignore the memory types and get the base and top
based on the memory map descriptors.
Now that I need to get the phys base (from previous patch discussion),
I will need to get the range, doing something like:
static efi_status_t efi_get_ram_range(u64 *base, u64 *top)
{
struct efi_boot_memmap *map __free(efi_pool) = NULL;
u64 ram_base = ULLONG_MAX, ram_top = 0;
efi_status_t status;
int i, nr_desc;
status = efi_get_memory_map(&map, false);
if (status != EFI_SUCCESS)
return status;
nr_desc = map->map_size / map->desc_size;
for (i = 0; i < nr_desc; i++) {
efi_memory_desc_t *d;
d = efi_memdesc_ptr((unsigned long)map->map, map->desc_size, i);
ram_base = min(ram_base, d->phys_addr);
ram_top = max(ram_top,
d->phys_addr + d->num_pages * EFI_PAGE_SIZE);
}
if (!ram_top)
return EFI_NOT_FOUND;
*base = round_down(ram_base, EFI_POISON_UNIT_SIZE);
*top = round_up(ram_top, EFI_POISON_UNIT_SIZE);
return EFI_SUCCESS;
}
is it what you had in mind?
Thanks,
--breno
next prev parent reply other threads:[~2026-09-07 14:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 12:03 [PATCH v3 0/5] efi: mm/memory-failure: keep hardware-poisoned pages out of the next kexec Breno Leitao
2026-08-26 12:03 ` [PATCH v3 1/5] mm/memory-failure: efi: add the LINUX_EFI_POISONED_MEMORY configuration table Breno Leitao
2026-08-28 13:47 ` Kiryl Shutsemau
2026-09-07 14:27 ` Breno Leitao
2026-08-26 12:03 ` [PATCH v3 2/5] mm/memory-failure: libstub: install the poisoned-memory EFI table Breno Leitao
2026-08-28 13:59 ` Kiryl Shutsemau
2026-09-07 14:47 ` Breno Leitao [this message]
2026-08-26 12:03 ` [PATCH v3 3/5] mm/memory-failure: efi: record hardware-poisoned frames into the poisoned-memory table Breno Leitao
2026-08-28 14:11 ` Kiryl Shutsemau
2026-09-07 15:23 ` Breno Leitao
2026-08-26 12:03 ` [PATCH v3 4/5] mm/memory-failure: add a helper to poison a frame at boot Breno Leitao
2026-08-26 12:03 ` [PATCH v3 5/5] mm/memory-failure: efi: replay the poisioned page in the next kernel Breno Leitao
2026-08-28 14:35 ` Kiryl Shutsemau
2026-09-07 12:58 ` [PATCH v3 0/5] efi: mm/memory-failure: keep hardware-poisoned pages out of the next kexec Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ap7OBwOs8BKGUJh8@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=david@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.