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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox