[PATCH] kho: try to allocate contiguous memory for kexec segments

[PATCH] kho: try to allocate contiguous memory for kexec segments

[Michal Clapinski]

This allows us to skip relocations (and maybe checksum calculation
in the future).

kho_scratch is marked as MIGRATE_CMA but isn't actually given to the
CMA, so it should only contain movable allocations, therefore this
should always succeed.

Signed-off-by: Michal Clapinski <mclapinski@google.com>
---
 kernel/kexec_core.c                |  6 +++++-
 kernel/liveupdate/kexec_handover.c | 21 +++++++++++++++++----
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index dc770b9a6d05..cba3ce985aa9 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -43,6 +43,7 @@
 #include <linux/kmsg_dump.h>
 #include <linux/dma-map-ops.h>
 #include <linux/sysfs.h>
+#include <linux/kexec_handover.h>
 
 #include <asm/page.h>
 #include <asm/sections.h>
@@ -566,7 +567,10 @@ static void kimage_free_cma(struct kimage *image)
 			continue;
 
 		arch_kexec_pre_free_pages(page_address(cma), nr_pages);
-		dma_release_from_contiguous(NULL, cma, nr_pages);
+		if (kho_is_enabled())
+			free_contig_range(page_to_pfn(cma), nr_pages);
+		else
+			dma_release_from_contiguous(NULL, cma, nr_pages);
 		image->segment_cma[i] = NULL;
 	}
 
diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 4834a809985a..289fd5948fd2 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1770,15 +1770,28 @@ static int kho_walk_scratch(struct kexec_buf *kbuf,
 	return ret;
 }
 
+static void kho_try_alloc_contig(struct kexec_buf *kbuf)
+{
+	unsigned long start_pfn = PFN_DOWN(kbuf->mem);
+	unsigned long nr_pages = kbuf->memsz >> PAGE_SHIFT;
+
+	if (alloc_contig_range(start_pfn, start_pfn + nr_pages,
+			       ACR_FLAGS_CMA, GFP_KERNEL))
+		return;
+
+	kbuf->cma = pfn_to_page(start_pfn);
+	arch_kexec_post_alloc_pages(page_address(kbuf->cma), nr_pages, 0);
+}
+
 int kho_locate_mem_hole(struct kexec_buf *kbuf,
 			int (*func)(struct resource *, void *))
 {
-	int ret;
-
 	if (!kho_enable || kbuf->image->type == KEXEC_TYPE_CRASH)
 		return 1;
 
-	ret = kho_walk_scratch(kbuf, func);
+	if (!kho_walk_scratch(kbuf, func))
+		return -EADDRNOTAVAIL;
 
-	return ret == 1 ? 0 : -EADDRNOTAVAIL;
+	kho_try_alloc_contig(kbuf);
+	return 0;
 }
-- 
2.54.0.929.g9b7fa37559-goog

Re: [PATCH] kho: try to allocate contiguous memory for kexec segments

[Michał Cłapiński]

On Mon, Jun 1, 2026 at 9:30 PM Michal Clapinski <mclapinski@google.com> wrote:
>
> This allows us to skip relocations (and maybe checksum calculation
> in the future).
>
> kho_scratch is marked as MIGRATE_CMA but isn't actually given to the
> CMA, so it should only contain movable allocations, therefore this
> should always succeed.

Now that I think about it, this is only true on the primary boot. On
subsequent boots, kho scratch will contain memblock allocations
forever. I should have tested it more than once.

I have no idea how probable it is that I will find enough movable/free
memory in kho scratch for this to ever succeed. I'll give it more
thought.

Re: [PATCH] kho: try to allocate contiguous memory for kexec segments

[Pratyush Yadav]

On Mon, Jun 01 2026, Michal Clapinski wrote:

> This allows us to skip relocations (and maybe checksum calculation
> in the future).

I'm confused. Doesn't your patch "kexec_file: skip checksum verification
when safe" [0] skip the checksum for KHO already? So this only skips the
relocations part then?

And based on the discussion on that thread, relocations don't seem to
take much time. So is there a real need for this patch?

[0] https://lore.kernel.org/kexec/20260602123311.1841746-1-mclapinski@google.com/

>
> kho_scratch is marked as MIGRATE_CMA but isn't actually given to the
> CMA, so it should only contain movable allocations, therefore this
> should always succeed.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH] kho: try to allocate contiguous memory for kexec segments

[Michał Cłapiński]

On Tue, Jun 2, 2026 at 6:58 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> On Mon, Jun 01 2026, Michal Clapinski wrote:
>
> > This allows us to skip relocations (and maybe checksum calculation
> > in the future).
>
> I'm confused. Doesn't your patch "kexec_file: skip checksum verification
> when safe" [0] skip the checksum for KHO already? So this only skips the
> relocations part then?
>
> And based on the discussion on that thread, relocations don't seem to
> take much time. So is there a real need for this patch?

I sent this patch out yesterday, then realized it wasn't going to work
so I abandoned this approach.
Today I sent patch [0] that skips the checksum for KHO, so this patch
is no longer needed.

> [0] https://lore.kernel.org/kexec/20260602123311.1841746-1-mclapinski@google.com/
>
> >
> > kho_scratch is marked as MIGRATE_CMA but isn't actually given to the
> > CMA, so it should only contain movable allocations, therefore this
> > should always succeed.
> >
> > Signed-off-by: Michal Clapinski <mclapinski@google.com>
> [...]
>
> --
> Regards,
> Pratyush Yadav

Re: [PATCH] kho: try to allocate contiguous memory for kexec segments

[Pratyush Yadav]

On Tue, Jun 02 2026, Michał Cłapiński wrote:

> On Tue, Jun 2, 2026 at 6:58 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> On Mon, Jun 01 2026, Michal Clapinski wrote:
>>
>> > This allows us to skip relocations (and maybe checksum calculation
>> > in the future).
>>
>> I'm confused. Doesn't your patch "kexec_file: skip checksum verification
>> when safe" [0] skip the checksum for KHO already? So this only skips the
>> relocations part then?
>>
>> And based on the discussion on that thread, relocations don't seem to
>> take much time. So is there a real need for this patch?
>
> I sent this patch out yesterday, then realized it wasn't going to work
> so I abandoned this approach.
> Today I sent patch [0] that skips the checksum for KHO, so this patch
> is no longer needed.

Makes sense, thanks for clarifying.

[...]

-- 
Regards,
Pratyush Yadav