[BUG] KHO handover hangs when memmap reserves PMEM

[Mike Rapoport]

On Tue, Oct 06, 2026 at 07:02:22PM +0100, Chris Bainbridge wrote:
> On Tue, Oct 06, 2026 at 12:55:31PM +0200, Mike Rapoport wrote:
> > On Sat, Oct 03, 2026 at 06:02:27PM +0100, Chris Bainbridge wrote:
> > > Hello,
> > > 
> > > I am reporting a regression in KHO handover.
> > > 
> > > In the most recent Ubuntu 26.10 beta mini-ISO releases (2026-09-18 onwards),
> > > the first kernel reserves RAM for the downloaded ISO with a memmap directive
> > > such as memmap=<size>!4G, then kexecs a second kernel. On affected kernels, the
> > > first kernel reaches "kexec_core: Starting new kernel", but the second kernel
> > > produces no further output and QEMU spins at 100% CPU. On unaffected kernels,
> > > the second kernel starts and finds /dev/pmem0 with the expected "Persistent
> > > Memory (legacy)" range in /proc/iomem.
> > 
> > TO make sure I understand this correctly, you enable KHO in the builds of
> > the installer kernel and then the installer command line explicitly enables
> > KHO.
> 
> Yes.
> 
> > Is there anything you actually preserve with KHO when kexec'ing the second
> > kernel?
> 
> No. kho=off is a valid workaround for the mini ISO.

I'd even say that setting CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=n and even
CONFIG_KEXEC_HANDOVER=n is a reasonable choice for a distro kernel.

We don't have CONFIG_EXPERIMENTAL anymore, otherwise kho and luo would be
gated by it.

> I only reported it as a regression here because this was working until
> the bisected commit was merged. If this is intended behaviour then it is
> not a problem.

Thanks for the clarification. 

This is a bug, but since it happens for a combination of an opt-in option
(kho) and a hack (memmap=) I consider it low priority.

-- 
Sincerely yours,
Mike.