Re: [RFC PATCH 0/2] arm64/hyperv: Enable kexec reboot support

Shradha Gupta <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-kernel
Message-ID <aowKTktjAeA9H9/W@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Fri, Aug 21, 2026 at 11:14:49AM +0100, Catalin Marinas wrote:
> On Fri, Aug 14, 2026 at 02:31:28AM -0700, Shradha Gupta wrote:
> > Kexec reboot consistently fails on ARM64 Hyper-V guests (Azure VMs).
> > During the kexec shutdown path, VMBus channels are never cleaned up,
> > so in the fresh kexec kernel startup hv_acpi_init() blocks because
> > the hypervisor still holds the old kernel's VMBus session open.
> > 
> > This is because ARM64 lacks the VMBus teardown that x86 performs during
> > kexec via hv_machine_shutdown(). On x86, machine_ops.shutdown is
> > overridden to send CHANNELMSG_UNLOAD and disable SynIC before CPUs
> > go offline. ARM64 has no equivalent mechanism.
> 
> I'm really not keen on such hook, a bare pointer you set elsewhere. Not
> sure it was discussed before but can you not use the syscore_shutdown()
> mechanism? This hook got added in 2023, so the 2022 discussion you
> referenced precedes it.
> 
> -- 
> Catalin

Thanks for the suggestion, Catalin.

I looked into syscore_shutdown() and it should work. The
syscore_shutdown() call in the kexec path runs after
device_shutdown() and before smp_shutdown_nonboot_cpus(),
which is exactly the window where VMBus teardown needs to happen.
It does run before cpu_hotplug_enable() (unlike the x86 path
where hv_kexec_handler runs inside machine_shutdown, after
cpu_hotplug_enable), but that should be safe because
cpuhp_remove_state() acquires cpus_read_lock, which should be
independent of the cpu_hotplug_disabled flag.

The implementation would override hv_setup_kexec_handler() in
arch/arm64/hyperv/mshyperv.c to register a syscore_ops.shutdown
callback, guarded by kexec_in_progress. No ARM64 arch changes needed,
and other shutdown paths (reboot, halt, poweroff, kdump) should also be
unaffected.

I am testing this now and will send a v2 with the updated approach.

Shradha
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.