S3 support in Q35

[krystian-hebel]

Dasharo version (if applicable)

v0.2.0

Dasharo variant (if applicable)

QEMU Q35

Affected component(s) or functionality (if applicable)

S3 sleep and resume

Brief summary

Analyze feasibility of support for S3 sleep for this platform. QEMU monitor has system_wakeup function which suggests it should be possible. OVMF required S3 to be disabled due to how UEFI variables are implemented there, but it is different with coreboot.

Additional context

S3 isn't supported by firmware for this emulated platform. Ubuntu seems to be able to halt the system, but instead of waking up, firmware does full initialization.

[Tonttu84]

Hello. Im a fresh graduate from Hive Helsinki (part of the 42 school network). Im willing to try solving this problem. Seems like there are no warmup level problems that require solving at the moment so I came to easy problems instead. I see that the problem is quite old, is it still valid?

I can also work on any other issue that requires help and is suitable for a junior with a good knowledge of C and who is studying assembly currently.

[LubuSeb]

Hi 3mdeb/Dasharo maintainers, I'd like to take this bounty if it is still available. My intended first pass is limited to feasibility validation rather than jumping straight into firmware changes: (1) boot the current QEMU Q35/Dasharo path locally, (2) reproduce the current S3 suspend/resume behavior and system_wakeup result, (3) document logs, commands, and whether the resume path needs firmware, coreboot, ACPI, or QEMU-side work, and (4) propose the smallest next implementation path or report blockers. I'll wait for assignment before starting the bounty work, per your program rules. Please assign me if this scope matches.

[pietrushnic]

@macpijan @BeataZdunczyk cc

[emreglrr]

I would like to claim this bounty and request assignment.

I will work on #902 first, before taking on #542. This work will use Codex assistance, with all implementation decisions, commands, logs, and validation results documented for maintainer review.

Proposed scope:

1. Reproduce the current QEMU Q35 S3 behavior from a clean checkout using the current Dasharo release and record the exact QEMU, firmware, and guest configuration.
2. Trace the suspend/resume path across generated ACPI tables, coreboot resume handling, and QEMU system_wakeup to identify why wake performs full initialization.
3. Propose the smallest firmware-side change that enables a real S3 resume, and confirm the direction here before broadening the patch.
4. Add a repeatable regression test, preferably in open-source-firmware-validation, which enters S3, triggers system_wakeup, and proves that the guest resumed rather than cold-booted.
5. Submit a focused PR with reproduction steps, before/after logs, test results, and documented limitations.

Initial estimate: 5-7 working days after assignment and scope confirmation. I will not start implementation until a maintainer confirms assignment, in accordance with the bounty-program rules.

[zkasuran]

I built coreboot for QEMU Q35 and ran a live S3 suspend/wake test to answer this concretely.

It is feasible. Here is the exact mechanism and the remaining work.

Root cause: on the S3 wake QEMU Q35 raises PM1_STS.WAK_STS but resets PM1_CNT, so SLP_TYP reads back 0. coreboot's common southbridge_detect_s3_resume() decides S3 by reading SLP_TYP == ACPI_S3, which QEMU has already cleared, so it never fires and the board takes a full cold boot on wake. That is exactly the reported symptom. PMBASE is set up correctly, so it is not a PM-base problem. Real ICH9 latches SLP_TYP across S3; QEMU does not, which is the whole divergence.

Detection fix that works: read PM1_STS.WAK_STS instead of SLP_TYP (write-1-to-clear after, gated by acpi_s3_resume_allowed()). Also select HAVE_ACPI_RESUME and advertise S3 in the DSDT. With that, coreboot prints "S3 Resume" on wake where before it printed only "Normal boot".

Still open: the end-to-end OS resume. With a synthetic test guest the firmware enters the S3 path but the guest still returns cold, so the ramstage acpi_resume() to FACS-waking-vector handoff needs finishing; it also needs a real OS guest (the Ubuntu the issue mentions) to verify. I am glad to complete the implementation and add an OSFV regression test (enter S3, system_wakeup, assert a resume rather than a cold boot) if you would like to assign it.

AI assistance (Claude, Anthropic) was used for the investigation. The design and verification are mine. The behavior above is from a real build and QEMU run.

[junkurera13]

I'd like to request assignment on this bounty-easy issue.

I've read the prior comments, including @zkasuran's Aug 8 feasibility write-up (QEMU clearing SLP_TYP on wake while PM1_STS.WAK_STS remains set; coreboot's southbridge_detect_s3_resume() missing the resume path).

Proposed next work after assignment:

1. Independently reproduce on current Dasharo QEMU Q35 (v0.2.0 or newer) and confirm the WAK_STS vs SLP_TYP behavior with logs.
2. Land the smallest firmware-side detection fix (HAVE_ACPI_RESUME / DSDT S3 / WAK_STS-based detect as appropriate) and finish the ramstage acpi_resume() → FACS waking-vector handoff so a real guest resumes instead of cold-booting.
3. Verify with an Ubuntu (or similar) guest: S3 suspend → QEMU system_wakeup → resume, not full init.
4. Add a repeatable OSFV regression test for that path.
5. Open a focused PR with reproduction steps, before/after logs, and limitations.

I will wait for maintainer assignment before treating this as claimed work, per the 3mdeb bounty program rules, and will post progress updates once assigned.

AI assistance will be disclosed on any PR.

[junkurera13]

Update: opened a firmware PR for the QEMU Q35 S3 path:

Dasharo/coreboot#960

It enables HAVE_ACPI_RESUME, uses QEMU-correct _S3/_S5, detects resume via WAK_STS on Q35, and wires romstage handoff for the waking vector. Still needs a maintainer assignment for the bounty and an end-to-end Ubuntu + system_wakeup verification run.

[junkurera13]

@macpijan @BeataZdunczyk @pietrushnic — following up on assignment for this bounty-easy.

PR is open and CI (pre-commit) is green:
Dasharo/coreboot#960

Happy to iterate on review feedback and to add an OSFV regression once the firmware path looks right. Please assign me (junkurera13) if you want this claimed under the 3mdeb bounty program.

[junkurera13]

Quick CI note on Dasharo/coreboot#960 :

GitHub Actions for the Dasharo workflow is currently action_required (first-time contributor workflow approval). pre-commit.ci already passed. If a maintainer can approve the workflow run, that would help validation move forward:

https://github.com/Dasharo/coreboot/actions/runs/34181387416

[junkurera13]

Verification update (stock qemu_q35_v0.2.1 under QEMU):

• Ubuntu 22.04 boots fine with -machine q35,smm=on + pflash.
• /sys/power/state is absent on the guest — firmware is not exposing ACPI sleep, so S3 cannot be entered from the OS.
• QEMU system_wakeup correctly reports the guest is not suspended.

This supports the PR approach (advertise QEMU-correct _S3 + resume detect). Building a patched ROM next for before/after.

[junkurera13]

Update: firmware S3 path on Dasharo/coreboot#960 now verifies end-to-end in QEMU via s3-verify.sh (PASS): detect resume → restore ramstage → find FACS → jump waking vector (Q35VEC).

Still hoping for assignment under the bounty-easy program when a maintainer has a moment (@macpijan @BeataZdunczyk @pietrushnic).