From: Pratyush Yadav <pratyush@kernel.org>
To: Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jason Miu <jasonmiu@google.com>
Cc: kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 11/12] kho: return virtual address of mem_map
Date: Wed, 29 Apr 2026 15:39:13 +0200 [thread overview]
Message-ID: <20260429133928.850721-12-pratyush@kernel.org> (raw)
In-Reply-To: <20260429133928.850721-1-pratyush@kernel.org>
From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
There are currently 3 callers of kho_get_mem_map_phys(). Two of them,
kho_mem_retrieve() and kho_extend_scratch() need the virtual address.
The third, kho_populate() doesn't care. Make things simpler by
directly returning the virtual address. Rename kho_get_mem_map_phys() to
kho_get_mem_map() to accurately reflect what it returns.
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
kernel/liveupdate/kexec_handover.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index c2b843a5fb28..2e13b80d1c7d 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -625,10 +625,11 @@ static int __init kho_preserved_memory_reserve(unsigned long key, void *data)
return 0;
}
-/* Returns physical address of the preserved memory map from FDT */
-static phys_addr_t __init kho_get_mem_map_phys(const void *fdt)
+/* Returns virtual address of the preserved memory map from FDT */
+static __init void *kho_get_mem_map(const void *fdt)
{
const void *mem_ptr;
+ phys_addr_t mem_map_phys;
int len;
mem_ptr = fdt_getprop(fdt, 0, KHO_FDT_MEMORY_MAP_PROP_NAME, &len);
@@ -637,7 +638,11 @@ static phys_addr_t __init kho_get_mem_map_phys(const void *fdt)
return 0;
}
- return get_unaligned((const u64 *)mem_ptr);
+ mem_map_phys = get_unaligned((const u64 *)mem_ptr);
+ if (!mem_map_phys)
+ return NULL;
+
+ return phys_to_virt(mem_map_phys);
}
/*
@@ -932,15 +937,15 @@ void __init kho_extend_scratch(void)
.key = kho_ext_mark_scratch,
};
struct kho_radix_tree radix;
- phys_addr_t prev_end = 0, mem_map_phys;
+ phys_addr_t prev_end = 0;
int err = 0;
if (!is_kho_boot())
return;
/* Make sure the KHO radix tree is initialized. */
- mem_map_phys = kho_get_mem_map_phys(kho_get_fdt());
- err = kho_radix_init_tree(&kho_in.radix_tree, phys_to_virt(mem_map_phys));
+ err = kho_radix_init_tree(&kho_in.radix_tree,
+ kho_get_mem_map(kho_get_fdt()));
if (err)
goto print;
@@ -1587,11 +1592,9 @@ static int __init kho_mem_retrieve(const void *fdt)
const struct kho_radix_walk_cb cb = {
.key = kho_preserved_memory_reserve,
};
- phys_addr_t mem_map_phys;
int err;
- mem_map_phys = kho_get_mem_map_phys(fdt);
- err = kho_radix_init_tree(&kho_in.radix_tree, phys_to_virt(mem_map_phys));
+ err = kho_radix_init_tree(&kho_in.radix_tree, kho_get_mem_map(fdt));
if (err)
return err;
@@ -1816,8 +1819,7 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
{
unsigned int scratch_cnt = scratch_len / sizeof(*kho_scratch);
struct kho_scratch *scratch = NULL;
- phys_addr_t mem_map_phys;
- void *fdt = NULL;
+ void *fdt = NULL, *mem_map;
bool populated = false;
int err;
@@ -1840,8 +1842,8 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
goto unmap_fdt;
}
- mem_map_phys = kho_get_mem_map_phys(fdt);
- if (!mem_map_phys)
+ mem_map = kho_get_mem_map(fdt);
+ if (!mem_map)
goto unmap_fdt;
scratch = early_memremap(scratch_phys, scratch_len);
--
2.54.0.545.g6539524ca2-goog
next prev parent reply other threads:[~2026-04-29 13:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 13:39 [PATCH 00/12] kho: make boot time huge page allocation work nicely with KHO Pratyush Yadav
2026-04-29 13:39 ` [PATCH 01/12] kho: generalize radix tree APIs Pratyush Yadav
2026-05-04 14:44 ` Pasha Tatashin
2026-05-05 11:20 ` Jork Loeser
2026-05-05 12:54 ` Pratyush Yadav
2026-04-29 13:39 ` [PATCH 02/12] kho: store incoming radix tree in kho_in Pratyush Yadav
2026-04-29 13:39 ` [PATCH 03/12] kho: add a struct for radix callbacks Pratyush Yadav
2026-04-29 13:39 ` [PATCH 04/12] kho: add callback for table pages Pratyush Yadav
2026-04-29 13:39 ` [PATCH 05/12] kho: add data argument to radix walk callback Pratyush Yadav
2026-04-29 13:39 ` [PATCH 06/12] kho: allow early-boot usage of the KHO radix tree Pratyush Yadav
2026-04-29 13:39 ` [PATCH 07/12] kho: allow destroying " Pratyush Yadav
2026-04-29 13:39 ` [PATCH 08/12] kho: add kho_radix_init_tree() Pratyush Yadav
2026-04-29 13:39 ` [PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT Pratyush Yadav
2026-04-29 13:39 ` [PATCH 10/12] kho: extended scratch Pratyush Yadav
2026-04-29 13:39 ` Pratyush Yadav [this message]
2026-04-29 13:39 ` [PATCH 12/12] mm/hugetlb: make bootmem allocation work with KHO Pratyush Yadav
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=20260429133928.850721-12-pratyush@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@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