From: Shradha Gupta <shradhagupta@linux.microsoft.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Long Li <longli@microsoft.com>
Cc: Shradha Gupta <shradhagupta@linux.microsoft.com>,
linux-arm-kernel@lists.infradead.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
Mark Rutland <mark.rutland@arm.com>,
Marc Zyngier <maz@kernel.org>,
Michael Kelley <mikelley@microsoft.com>,
Shradha Gupta <shradhagupta@microsoft.com>
Subject: [RFC PATCH 0/2] arm64/hyperv: Enable kexec reboot support
Date: Fri, 14 Aug 2026 02:31:28 -0700 [thread overview]
Message-ID: <20260814093133.3191250-1-shradhagupta@linux.microsoft.com> (raw)
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.
Why existing notification mechanisms don't work:
- Reboot notifiers: Fire too early - they run inside
kernel_restart_prepare(), BEFORE device_shutdown(). VMBus UNLOAD
must happen AFTER device_shutdown() so that PCI drivers can clean
up interrupt mappings (PCI_DELETE_INTERRUPT_MESSAGE) before UNLOAD
force-closes channels. Sending UNLOAD first causes interrupt
mapping leaks because the mappings aren't released on channel
close.
- Device .shutdown callbacks: Too narrow - these handle per-device
cleanup (e.g., individual VMBus channel teardown), but cannot
perform bus-level operations like sending the global VMBus UNLOAD
message or removing the SynIC CPU hotplug state via
cpuhp_remove_state().
- VMBus parent device .shutdown callback: Also insufficient -
cpuhp_remove_state() for SynIC teardown must run after all device
shutdown completes, not during it. A parent .shutdown callback
still executes within device_shutdown().
- The required window is: after device_shutdown() completes, after
cpu_hotplug_enable(), but before smp_shutdown_nonboot_cpus(). That
window exists inside machine_shutdown(), which currently has no hook.
The need for an ARM64 shutdown hook was previously discussed in [1]
but lacked a concrete failure case at the time. We now have one.
[1] https://lore.kernel.org/linux-arm-kernel/427a8277-49f0-4317-d6c3-4a15d7070e55@igalia.com/
This RFC proposes fixing kexec on ARM64 Hyper-V guests with:
Patch 1: A platform hook (arm64_pre_smp_shutdown_hook) in ARM64's
machine_shutdown(), analogous to x86's machine_ops.shutdown. This
runs after device_shutdown() and cpu_hotplug_enable(), allowing
platform code to inject pre-shutdown logic at the right point in
the kexec path.
Design choices I'd like feedback on:
- Single function pointer vs full machine_ops struct: ARM64 uses
kernel-wide APIs (register_restart_handler, register_platform_power_off)
for restart/poweroff rather than x86's monolithic machine_ops, so
a targeted hook seemed more consistent with the ARM64 pattern.
- On ARM64, machine_shutdown() is only called from kernel_kexec(),
unlike x86/powerpc where it's also called from restart/halt/poweroff.
Patch 2: Uses this hook to call hv_kexec_handler() which performs:
- vmbus_initiate_unload(): sends CHANNELMSG_UNLOAD to host
- cpuhp_remove_state(): disables SynIC (SIMP, SIEFP, SINT) on
all CPUs, ensuring the kexec'd kernel starts with clean state
Tested on ARM64 Azure VMs (Ubuntu 22.04, multiple vCPU configs):
- kexec reboot succeeds, VM comes back online with SSH
- Normal reboot/poweroff unaffected
- Multiple consecutive kexec cycles pass
Looking for feedback on:
1. Is the single function pointer hook acceptable for ARM64, or would
the ARM64 maintainers prefer a registration API or __weak function?
2. Should this be arm64-specific or generic kexec infrastructure?
Shradha Gupta (2):
arm64: Add pre-shutdown hook to machine_shutdown()
arm64/hyperv: Add kexec handler using machine_shutdown hook
arch/arm64/hyperv/mshyperv.c | 37 ++++++++++++++++++++++++++++
arch/arm64/include/asm/system_misc.h | 2 ++
arch/arm64/kernel/process.c | 13 ++++++++++
3 files changed, 52 insertions(+)
--
2.43.0
next reply other threads:[~2026-08-14 9:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 9:31 Shradha Gupta [this message]
2026-08-14 9:31 ` [RFC PATCH 1/2] arm64: Add pre-shutdown hook to machine_shutdown() Shradha Gupta
2026-08-14 9:38 ` sashiko-bot
2026-08-17 13:28 ` Shradha Gupta
2026-08-14 9:32 ` [RFC PATCH 2/2] arm64/hyperv: Add kexec handler using machine_shutdown hook Shradha Gupta
2026-08-14 9:49 ` sashiko-bot
2026-08-17 13:29 ` Shradha Gupta
2026-08-21 9:17 ` [RFC PATCH 0/2] arm64/hyperv: Enable kexec reboot support Shradha Gupta
2026-08-21 10:14 ` Catalin Marinas
2026-08-24 9:09 ` Shradha Gupta
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=20260814093133.3191250-1-shradhagupta@linux.microsoft.com \
--to=shradhagupta@linux.microsoft.com \
--cc=catalin.marinas@arm.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mikelley@microsoft.com \
--cc=shradhagupta@microsoft.com \
--cc=wei.liu@kernel.org \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.