fix(docs): q35 does boot a bare ELF through -kernel, given a PVH note

[MatejGomboc]

Pull Request

Summary

Five places told contributors that q35 has "no bare-ELF equivalent of -kernel": CLAUDE.md § Architectures, the README's Status, the x86_64 module docs, xtask's require_bootable refusal and a comment in ci_pr.yml. That claim is false. QEMU's x86 loader does take a 64-bit ELF through -kernel, provided it carries a Xen PVH note. This PR corrects all five without choosing a boot path.

Explanation for the maintainer

What QEMU actually does, read in the pinned 11.0.3 source (hw/i386/x86-common.c, shared by pc and q35):

• load_elfboot loads an ELF with load_elf, asking for the XEN_ELFNOTE_PHYS32_ENTRY note.
• If the note is missing, it stops with Error loading uncompressed kernel without PVH ELF Note.
• The Multiboot path runs first, but it refuses 64-bit images ("Cannot load x86-64 image, give a 32bit one", hw/i386/multiboot.c).
• So a 64-bit ELF boots through -kernel only with a PVH note.

Reproduced: today's x86_64 image, run on the pinned QEMU 11.0.3 with -machine q35 -kernel …, fails with exactly that error.

Why the wording is neutral: the x86_64 boot research (#22's hand-off) recommends PVH now and a UEFI stub later. That's a design decision for the future x86_64 boot RFC, so the corrected text only states the fact: the image has neither the PVH note nor a UEFI stub. Real hardware still needs UEFI, as the constitution's bring-up order says.

Code change: one. xtask's refusal message is reworded; behaviour is unchanged (x86_64 is still refused before QEMU runs).

Which pillar does this serve?

Toil: the documents must describe the tree truthfully (Constitution §5.2 and §5.4).

If this changes a document or the constitution

• Cross-references still resolve; no clause is left contradicting another
• If this is a constitution amendment, it is the maintainer's, and docs/CHANGELOG.md records it (not an amendment)
• No section other documents cite has been renumbered

Borrow Ledger

• I checked the Borrow Ledger (CONSTITUTION.md §4) for this subsystem
• The verdict for this subsystem is: write ourselves (boot path) — no code added
• Vendored code retains its original licence notices; new files carry an SPDX header (no new files)

unsafe register

• New unsafe blocks: None
• Every new unsafe block carries a // SAFETY: comment
• Every unsafe block is inside a module CLAUDE.md designates for it
• I have listed them in the session summary / PR description above

Checklist

All run locally and passing, mirroring ci_pr.yml:

• Toolchain pin, British spelling, cargo fmt --all --check and markdownlint-cli2
• Clippy with -D warnings and debug/release builds of setonix-kernel (--all-features) for both Tier-1 targets
• setonix-capability clippy for both targets; host clippy and tests (39 + doctests)
• xtask clippy and tests (8)
• Both boot tests on QEMU 11.0.3: Kaya! and BRK instruction
• cargo xtask boot-test --arch x86_64 prints the new refusal message

🤖 Generated with Claude Code

https://claude.ai/code/session_01D1gBBT3tN99wzeJjf3tLWW

---

Generated by Claude Code