Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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