emulation/qemu-q35: fix S3 wake detection and enable ACPI resume

[junkurera13]

Summary

Fixes S3 suspend/resume detection on the QEMU Q35 Dasharo path (dasharo-issues#902).

QEMU’s ACPI PM is not ICH9: S3 uses SLP_TYP=1, S5 uses 0, and on wake QEMU resets PM1_CNT while setting PM1_STS.WAK_STS. coreboot’s generic resume detect required SLP_TYP == ACPI_S3 (5), so romstage always took a cold boot after system_wakeup.

This change:

• Enables HAVE_ACPI_RESUME for qemu-q35
• Advertises QEMU-correct _S3 / _S5 in the DSDT
• Detects Q35 resume via WAK_STS (real ICH9 path unchanged)
• Wires romstage CBMEM / handoff for the ramstage waking-vector jump
• Uses QEMU S5 encoding in poweroff() on Q35

Closes: Dasharo/dasharo-issues#902 (partial — firmware path; needs guest verification)

Verification (still needed on a machine with QEMU + Ubuntu disk)

cp configs/config.emulation_qemu_x86_q35_uefi .config
make olddefconfig && make
# confirm CONFIG_HAVE_ACPI_RESUME=y

qemu-system-x86_64 -M q35 -m 2G -bios build/coreboot.rom \
  -serial stdio -monitor telnet:127.0.0.1:4444,server,nowait \
  -hda <ubuntu-disk>

Guest: systemctl suspend. Monitor: system_wakeup.

Expected serial: SB: Resume from S3 detected. then S3 Resume / OS waking vector — not only Normal boot.

Limitations

• Not run end-to-end with an Ubuntu guest in the build environment used for this PR
• Guests that never program FACS.firmware_waking_vector can still appear to cold-boot the payload after firmware detects S3
• No OSFV regression test included yet

AI disclosure

Implemented with Cursor cloud agent assistance. Design checked against QEMU ACPI PM behavior (acpi_pm_cnt_write / acpi_notify_wakeup / acpi_pm1_cnt_reset) and coreboot’s existing HAVE_ACPI_RESUME path. A human QEMU + OS resume run is still required before treating this as fully validated.

[junkurera13]

Thanks for taking a look when you can.

This targets dasharo-issues#902 (bounty-easy / QEMU Q35 S3). pre-commit is green; the Dasharo Actions workflow is waiting on first-time contributor approval:
https://github.com/Dasharo/coreboot/actions/runs/34181387416

Happy to address review feedback quickly. I can also add an OSFV-style regression once the firmware approach looks acceptable.

[junkurera13]

Stock-firmware verification (this machine)

Used published qemu_q35_v0.2.1 ROM with:

qemu-system-x86_64 -machine q35,smm=on -m 2G \
  -drive if=pflash,format=raw,file=qemu_q35.rom \
  -drive file=ubuntu-cloud.img,format=qcow2,if=none,id=disk0 \
  -device ide-hd,drive=disk0,bus=ide.0 \
  ...

Results on unpatched v0.2.1:

• Guest boots Ubuntu 22.04 on serial.
• /sys/power/state is missing (No such file or directory) — ACPI sleep is not offered to the OS.
• system_wakeup from the QEMU monitor returns: Error: Unable to wake up: guest is not in suspended state.

This matches #902: without QEMU-correct _S3 / resume support, the platform cannot enter a real S3 path from the guest.

Next: rebuild with this PR’s qemu-q35 changes and re-check that /sys/power/state includes mem, then suspend + system_wakeup.

[junkurera13]

Update: firmware path verified

Pushed follow-up commits on this PR (+796/−26, 15 files). s3-verify.sh PASS on QEMU 8.2.2:

• cold boot: s3resume=0
• after suspend/system_wakeup: s3resume=1, S3 Resume, FACS found, jump to waking vector, payload prints Q35VEC

Root-cause addendum beyond the earlier WAK_STS note: bootblock was zeroing the entire CAR DRAM window on S3 reset, which erased a waking vector in that range. Fix zeros only allocated CAR and parks the smoke vector at 0x1000.

Evidence file: Documentation/mainboard/emulation/qemu-q35-s3-verify.txt.

Still requesting assignment on dasharo-issues#902 for the bounty-easy payout path, and happy to add an Ubuntu guest pass / OSFV test if maintainers want that before merge.