Repository navigation
S3 support in Q35 #902
Description
Activity
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.
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_wakeupresult, (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.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:
- 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.
- Trace the suspend/resume path across generated ACPI tables, coreboot resume handling, and QEMU system_wakeup to identify why wake performs full initialization.
- Propose the smallest firmware-side change that enables a real S3 resume, and confirm the direction here before broadening the patch.
- 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.
- 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.
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_STSbut resetsPM1_CNT, soSLP_TYPreads back 0. coreboot's commonsouthbridge_detect_s3_resume()decides S3 by readingSLP_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 latchesSLP_TYPacross S3; QEMU does not, which is the whole divergence.Detection fix that works: read
PM1_STS.WAK_STSinstead ofSLP_TYP(write-1-to-clear after, gated byacpi_s3_resume_allowed()). Also selectHAVE_ACPI_RESUMEand 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.
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_TYPon wake whilePM1_STS.WAK_STSremains set; coreboot'ssouthbridge_detect_s3_resume()missing the resume path).Proposed next work after assignment:
- Independently reproduce on current Dasharo QEMU Q35 (
v0.2.0or newer) and confirm the WAK_STS vs SLP_TYP behavior with logs. - Land the smallest firmware-side detection fix (
HAVE_ACPI_RESUME/ DSDT S3 / WAK_STS-based detect as appropriate) and finish the ramstageacpi_resume()→ FACS waking-vector handoff so a real guest resumes instead of cold-booting. - Verify with an Ubuntu (or similar) guest: S3 suspend → QEMU
system_wakeup→ resume, not full init. - Add a repeatable OSFV regression test for that path.
- 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.
- Independently reproduce on current Dasharo QEMU Q35 (
Update: opened a firmware PR for the QEMU Q35 S3 path:
It enables
HAVE_ACPI_RESUME, uses QEMU-correct_S3/_S5, detects resume viaWAK_STSon Q35, and wires romstage handoff for the waking vector. Still needs a maintainer assignment for the bounty and an end-to-end Ubuntu +system_wakeupverification run.@macpijan @BeataZdunczyk @pietrushnic — following up on assignment for this bounty-easy.
PR is open and CI (pre-commit) is green:
Dasharo/coreboot#960Happy 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.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
Verification update (stock
qemu_q35_v0.2.1under QEMU):- Ubuntu 22.04 boots fine with
-machine q35,smm=on+ pflash. /sys/power/stateis absent on the guest — firmware is not exposing ACPI sleep, so S3 cannot be entered from the OS.- QEMU
system_wakeupcorrectly 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.- Ubuntu 22.04 boots fine with
- added a commit that references this issue
on Sep 8, 2026 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).
Dasharo version (if applicable)
v0.2.0Dasharo 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_wakeupfunction 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.