Skip to content

efi: Implement reset_system for Cloud Hypervisor - #424

Open
CMGS wants to merge 1 commit into
cloud-hypervisor:mainfrom
cocoonstack:fix/reset-system
Open

efi: Implement reset_system for Cloud Hypervisor#424
CMGS wants to merge 1 commit into
cloud-hypervisor:mainfrom
cocoonstack:fix/reset-system

Conversation

@CMGS

@CMGS CMGS commented Apr 1, 2026

Copy link
Copy Markdown

Implement the EFI ResetSystem runtime service to write to Cloud Hypervisor's AcpiShutdownDevice I/O port (0x600).

The function was intentionally left as a no-op to force Linux to use ACPI for shutdown. Linux does fall back correctly, but Windows calls ResetSystem(EfiResetShutdown) as its final shutdown step and does not fall back to ACPI. This causes the Cloud Hypervisor process to hang indefinitely after Windows shuts down.

On x86_64, write the appropriate value based on reset type:

  • EfiResetShutdown: SLP_TYP=5 + SLP_EN → triggers VM exit
  • EfiResetCold/EfiResetWarm: reboot value → triggers VM reset

On other architectures (aarch64, riscv64), the function remains a no-op — these platforms use PSCI for shutdown/reboot.

Scenario Before After
SSH shutdown /s /t 0 CH hangs forever 22s exit
ACPI power button CH hangs forever 19s exit

Linux guests are unaffected.

Fixes: #422

Signed-off-by: CMGS ilskdw@gmail.com

@CMGS
CMGS force-pushed the fix/reset-system branch from 51e84a4 to a76cafc Compare April 1, 2026 15:57
@CMGS
CMGS force-pushed the fix/reset-system branch 2 times, most recently from 90b672b to 8bef566 Compare April 16, 2026 03:44
@CMGS

CMGS commented Apr 16, 2026

Copy link
Copy Markdown
Author

seems ci failed due to arm64 runner itself

@CMGS
CMGS force-pushed the fix/reset-system branch from 8bef566 to 1fc1687 Compare July 29, 2026 15:37
The ResetSystem runtime service was intentionally left as a no-op to
force Linux to use ACPI for shutdown. However, Windows calls
ResetSystem(EfiResetShutdown) as its final shutdown step and does not
fall back to ACPI when the call returns. This causes the Cloud
Hypervisor process to hang indefinitely after Windows shuts down.

Write the appropriate value to Cloud Hypervisor's shutdown I/O port
(0x600) based on the reset type:
- EfiResetShutdown: SLP_TYP=5 + SLP_EN (triggers VM exit)
- EfiResetCold/Warm: reboot value (triggers VM reset)

The service is split into two phases because EFI applications like shim
call ResetSystem during early boot when MOK state import fails
(set_variable returns UNSUPPORTED). Writing to the shutdown port there
made VMs either shut down on Cloud Hypervisor or hang on QEMU during
boot. So reset_system_boot keeps the old no-op behavior during boot
services, and the port I/O only becomes active after ExitBootServices.

fixup_at_virtual remaps reset_system to its virtual address rather than
not_available, so ResetSystem still works after SetVirtualAddressMap,
which Windows needs to shut down on Cloud Hypervisor.

Linux guests are unaffected as they use ACPI directly.

Fixes: cloud-hypervisor#422

Signed-off-by: CMGS <ilskdw@gmail.com>
@CMGS
CMGS force-pushed the fix/reset-system branch from 1fc1687 to ecd5f0b Compare August 19, 2026 04:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

efi: reset_system is a no-op, Windows guests cannot shut down or reboot

1 participant