[Japabu]

Status: draft. Merged with main d7f269dbc at f9e44e0fb. It waits on the owner's item 53 (below): until it is decided, cargo run -- --arch aarch64 panics before userland. Review round 2's four items are answered (round-2 comment). Host CI, both image builds and the five QEMU rows the review asked for are green at the head. Metal at 4e32df68c: AMD passed, T14 testcases passed, T14 acpicase had no log, as predicted; its row is now unregistered (below).

Problem

cargo run -- --arch aarch64 handed over none of its four PCI claims. The loader's window list (each root bridge's Configuration() plus every unowned GCD MMIO range) counted ECAM and flash among the declared windows (#916). The owner's ruling: aperture discovery leaves the loader, AML stays in acpiserver, and a refused or missing declaration fails closed.

Owner item 53: a kernel driver's domain before the declaration

Main's IOVA allocator (K1, kernel::iova, #974) builds every domain clear of the root bridges' declared windows, and drops the old rule that placed a domain above the CPU's addresses where the unit translates wider. Option 1, an identity-placed domain for a kernel driver, was withdrawn on this PR on the premise that after step 10 no kernel driver needs a domain before the declaration. The kernel's virtio console still does: it comes up before acpiserver declares, so it gets no domain (iommu: no domain of its own for a device: no declaration of the root bridges' windows is held) and keeps the machine's addresses.

• On VT-d those are the identity domain's: the x86 console works, without the domain main gives it.
• On virt's SMMUv3 a stream with no domain aborts, so the console's first queue completes nothing and the kernel panics in wait_used (UART log, lines 204 to 213). The virt guest rows pass because their console bypasses the unit.

Options:

1. Recommended: a kernel driver's domain maps its pool at the pool's physical address. RAM is never inside a declared window, because the declaration's fence refuses a window over memory, so this needs no declaration. It is a translating domain that maps the pool alone. Cost: option 1's identity placement returns for the one kernel PCI driver left.
2. A kernel driver's domain hands out addresses only from the RAM-typed ranges of firmware's map: the same property as option 1, through the allocator, with more machinery.
3. The console bypasses the unit: no isolation for a DMA master.
4. The console declines a stream with no domain, and the kernel's console stays on the UART: cargo run's terminal shows nothing after the loader.

issues/an-aarch64-cargo-run-boot-hands-over-no-pci-claim.md stays open with this cause. This branch had closed it at 4f5142fea, where the boot handed over all four claims.

What this changes

• acpiserver declares the PCI roots, once, from the initialised namespace (system/acpiserver/src/apertures.rs):
  • A root is a PNP0A03/PNP0A08 device below no other. For each present root it reads _SEG, the bus range and the memory windows of _CRS (toyos_acpi::root_bridge), including Word, DWord, QWord and Extended descriptors, and steps over I/O.
  • It queries the root's _OSC under the PCI host bridge UUID: revision 1, Support = extended config space and MSI, Control asked = native hot-plug and the PCIe capability structure. It records the offer and makes no commit; Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934, which services hot-plug, commits.
  • Refused by name, with no root declared: a non-zero _TRA, a consumed range, an unknown descriptor, a second or out-of-range bus range, a root with no bus range, more than 16 roots, more than 64 windows across all roots.
• The declaration is per host bridge (toyos_abi::acpi::Apertures): segment, buses, the _OSC offer, a commit's grant, and a run of one shared window list. It travels through op::DECLARE on the acpi claim. Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934 consumes this shape.
• The kernel holds it (kernel/src/pcidev): only from the acpi claim's holder and only from Unknown; every record checked against the ABI, then every window together (whole, disjoint, none over RAM). Any failure refuses by name, wakes the waiters and stands as the answer. The holder's claim ending first withholds it (Ended).
• A PCI claim made before the declaration waits on its watch, on the claimant's syscall thread, for at most 30 s; one that waits it out withholds the declaration for the boot (Unanswered).
• Every metal boot fails on a refused declaration (Readback::declaration_not_refused), and the AMD row requires the declared-windows record.
• IOMMU, over main's allocator: a domain's allowed addresses are the unit's range less the backend's reserved ranges (RMRRs, IVMDs, the interrupt range, AMD-Vi's special range, the ITS doorbell), which each unit gives Domains::avoid, and less the declared windows, which each claim passes (OwnSpace::create(room, windows)). No declaration, no domain. The AMD-Vi and SMMU selftests, which run before any declaration with the test device on QEMU's root bus, pass none.
• The supervisor starts every acpi claim holder first, before the disk drivers (One block service and a driver per disk controller; input names each device; SCSI is its own crate (usbd step 10, PR 1 of 2) #962's order), whose claims wait for it. Since boot: the kernel hands the supervisor its images and parses no filesystem #994 the list begins with SYSTEM, so the holders are picked out of the whole list; taking them from its front missed acpiserver and made the_log_lands_on_the_boot_stick wait out the deadline, a defect the merge brought and f9e44e0fb fixes.
• Every image whose rows claim a PCI function starts acpiserver, main's benchcase and hostedclangcase now too, and a build host test holds it (every_config_that_claims_a_pci_function_starts_its_declarer; undeclaredcase is the one exception, booted to judge the refusal).
• acpicase has no storage. Its first acpi holder is a job, so no row declares before the supervisor's own claims; main's nvme and usbd rows there would wait out the deadline and refuse every claim. The probe's held-function arm moves to the console function the kernel drives.
• acpi_server_death is unregistered, with its judge and its job acpi_release: its job must hold the boot's first acpi claim, so nothing declares before usbd's stick claim and the T14 boot has no log (measured at 4e32df68c). No QEMU row can take its place, since QEMU's firmware hands over in ACPI mode. issues/the-acpi-servers-death-has-no-readback-on-the-t14.md, owned by the ACPI track, has re-registering all three as its exit.
• AArch64 gets the hardware-reduced acpi claim: ECAM for configuration, firmware memory through the direct map, no registers or ports, no new privilege.
• Deleted: loader/src/gcd.rs, loader/src/rootbridge.rs, PciRootBridgeIo, KernelArgs::root_bridge_windows and its count (KernelArgs 1504 → 472 bytes), the OVMF Configuration() fixture and its tests.
• Issues:
  • new: an-x86-machine-with-no-acpi-row-hands-over-no-pci-claim.md, and the-acpi-servers-death-has-no-readback-on-the-t14.md (below);
  • deleted: the-gcd-maps-held-mmio-descriptors-are-logged-nowhere.md (the loader reads no GCD map);
  • updated where they named the loader's reads: the hypervisor and ACPI tracks and the BarUnrouted tooling issue;
  • re-pointed from closed drafts: the four scheduler findings Design: the scheduler places by the machine's cache tree, orders fair work by EEVDF and reserves real time, in stages #872's S2/S3 were to settle now name the placement track; the speed track's Design: the kernel sizes its per-CPU state from the firmware's CPU count #865 line goes, since sched: placement reads the cache tree, and every per-CPU table is sized for the CPUs the firmware names #976 sized per-CPU tables for the CPUs firmware names; the ACPI track's _CST line drops Design: idle CPUs enter the deep idle states the firmware declares #870.
• Size: 80 files, +2220/−1133 against the merge base, tests included (measured).

What each judge establishes

• virt_claim_lpi requires pci: root 0000:00 _OSC: native hot-plug offered; VirtIts has a second root at bus 8.
• a_drives_row_holds_one_process_per_function requires q35's not offered.
• a_claim_waits_out_an_undeclared_machine (q35, no acpiserver): the first claim waits 30 s, and both are refused by name.
• acpi_mediated_access judges the Ended transition, and the console function's HeldFunction.
• domains_map_clear_of_the_host_bridges (T14) reads every mapping against the acpi claim's declared windows.
• amdvi_translates_the_stick_controller also requires the declaration.

Checks

Evidence: pr-935 at 415052dc7. That commit was published through the GitHub API after the clone was refused, which the owner is deciding on.

check	revision	result
cargo run -- --ci host	f9e44e0fb	exit 0, 93 steps green
--build-only, x86-64 and aarch64	f9e44e0fb	exit 0, 0
a_drives_row_holds_one_process_per_function, a_claim_waits_out_an_undeclared_machine, acpi_mediated_access, virt_claim_lpi, the_log_lands_on_the_boot_stick	f9e44e0fb	exit 0, 5 passed
the same five at e6dd4addf, before the supervisor fix	e6dd4addf	4 passed; the_log_lands_on_the_boot_stick stalled waiting for usbd, the defect fixed above
22 QEMU rows, host CI	1ffbdbaaf	exit 0 each (round 3 evidence above)
cargo run x86-64 / aarch64	1ffbdbaaf	boots / kernel panic, item 53
controls	earlier rounds	each red; none of the later merges touches the mutated lines
metal	4e32df68c	AMD testcases: 3 passed. T14 testcases: passed (3 windows declared, a claim waited 67 ms, _OSC: native hot-plug offered, buses 0x00..=0x79, no commit). T14 acpicase: no log, the predicted outcome.

Logs after 1ffbdbaaf are kept locally and not published, pending the owner's word on evidence publication.

Risks and open points

• The decision above blocks landing: aarch64 with the console behind the SMMU does not boot.
• acpi_server_death is unregistered until its T14 boot has a log (its issue, owned by the ACPI track).
• Every machine's claims depend on acpiserver, metal included; an x86 machine with no acpi row loses them all (its issue).
• benchcase now runs acpiserver beside osbench's measurement, since the stick's claim needs it.
• The AMD bench's _CRS is still unmeasured byte for byte; its next boot logs the bytes and the window count.
• The T14's firmware offers native hot-plug (measured at 4f5142fea); Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934 commits it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXEk8BBMDT8tXu4AnENB9Q

[Japabu]

Metal at 4f5142fea, run by the orchestrator: evidence commit 42550608c1e282100d36de07febe6b3cb9f83b80, stage-b/README.md, "Metal".

• T14: 4 passed over 2 boots (acpi_tables_loaded, claim_reuses_its_remapping_entry, domain_ends_below_the_host_bridges, usbd_drives_the_type_c_controller). Tables loaded in 54 ms and 55 ms; acpiserver started 1-2 ms before diskserver; declared mem 0xa0000..0xc0000, mem 0xa0800000..0xc0000000, mem 0x4000000000..0x8000000000; one claim waited 37 ms. The granted 0x0 of 0x0 lines are \_SB._OSC and the processors'. The host bridge's line is pci: root 0000:00 _OSC: native hot-plug granted.
• AMD bench: amdvi_translates_the_stick_controller passed: each kernel xHCI domain maps its one pool at identity. Tables loaded in 45 ms.
• Finding, a defect of this PR: the AMD bench's \_SB.PCI0._CRS has more than MAX_BRIDGE_WINDOWS (8) memory windows. So acpiserver declared no root and the kernel refused the declaration. No claim was made on that boot, so no row went red, but every process claim on that bench would be refused at this head. The fix is a larger per-root bound, or one window pool shared across roots, plus a host case from that bench's _CRS. I have not changed it while the review runs.

[Japabu]

Review of #935 at 4f5142fea (PCI apertures stage B)

Architecture

The ownership matches #916's design and the stage-B rulings. AML stays in acpiserver. The kernel holds a typed, write-once aperture::Held. The loader no longer asks UEFI about apertures. gcd.rs, rootbridge.rs, PciRootBridgeIo and KernelArgs::root_bridge_windows are gone with no residue: the only remaining match is a historical string in build/identity.rs:208's test fixture. KernelArgs is 456 bytes in the ABI's const assertions, the loader's initializer and the kernel's reader, all in one landing.

Admission is enforced by sys_acpi's held_by check and by Held::declare accepting only from Unknown. The claim's Drop calls declarer_gone, so a claim that ends without declaring moves the state to Ended. Both paths are host-tested.

Option 1 is implemented as ruled:

• Placement::Identity is used only by DeviceSpace::create, which serves the kernel's own drivers.
• Its map returns Iova::translated(phys). Nothing else is mapped into such a domain on VT-d or AMD-Vi; on the SMMU the ITS doorbell page is also mapped, which MSI requires and which is MMIO.
• It is refused when pmm::top() reaches past what the unit translates.
• Claimed functions keep Window::new, now taking the declaration as a parameter. IommuError::Undeclared and the Option threading are gone.

The RAM fence takes firmware_map() filtered by is_read_as_memory: usable memory plus ACPI reclaim and NVS. That covers every type the pmm hands pools out of, which is what the premise needs. It is a different source from the IOMMU's reserved regions, which come from RMRRs and IVMDs, and it should be. The fence runs after the kernel drivers' domains already exist, so it is a bug fence on the declaration, not a gate on option 1. The premise itself is a hardware fact.

window.rs's header was rewritten, not appended to.

The wait is sound:

• wait_until on DECLARATION runs with a Parkable::at_entry() on the claimant's syscall thread. For an endowed claim that is the supervisor's thread.
• It has a 30 s Deadline and never spins.
• A kill returns None, so the claim fails as Unusable.
• One expired deadline answers Unanswered for the whole boot. This is stated in the pcidev header and in DECLARATION_DEADLINE's doc. The undeclared row tests it: exactly one waited line, and both claims refused. It hides no transient: a declarer slower than 30 s leaves a named refusal on every claim.

Required

1. kernel/src/syscall/device.rs:181 / kernel/src/pcidev/mod.rs:425 / sdk/abi/src/syscall.rs:2119: a malformed record is refused silently and without becoming the answer.

   • RootBridge::decode returns None for a count > 16, a window_count > 8, an unknown _OSC word, a grant beside no answer, or first_bus > last_bus. That answers InvalidArgument, but the state stays Unknown, nothing is logged and nothing is posted.
   • acpi_declare's contract says InvalidArgument means a declaration "said in its log by name and leaving every PCI claim refused". For this path that is false.
   • Scenario: a hostile or buggy acpiserver sends count = 17. Every waiting claim keeps waiting toward its 30 s deadline with no line saying why, and a second, valid DECLARE is then admitted. That breaks "once", because a refused declaration is supposed to be the answer.
   • Fix: make a decode failure a named refusal through Held (for example a Refused::Record variant, logged and posted). decode currently has no test, so move it beside Held in toyos-pci and host-test each malformed field there.
   • Overlapping bus ranges of two roots on one segment are not refused either. That is harmless today, since only the windows are consumed and overlapping windows are caught by check, but see suggestion 2.

2. system/acpiserver/src/osc.rs:8-11 against :157-178: ToyOS commits native PCIe hot-plug control it does not perform, and the module header now states something false.

   • The header holds _OSC to the owner's _OSI condition: "each bit set only where ToyOS does what the bit promises". negotiate_root commits NATIVE_HOT_PLUG, and nothing services it until lifecycle 2. The PR's own risk section admits that on virt firmware hands hot-plug to an OS that does not act on it.
   • The stage-B ruling asks for the grant to be negotiated and logged. It does not set aside the owner's condition. That conflict is the owner's to settle, not the implementer's.
   • Smallest compliant fix: send the query only (Query flag set) and record what would be granted, then let lifecycle 2 commit once it can service hot-plug. Otherwise, get the owner's explicit agreement and rewrite the header to state the exception.

3. No silent debt: an x86 machine with no acpi row now loses every PCI claim.

   • kernel/src/arch/x86_64/acpi_mode.rs:234-250 mints no row for any of these: an unusable FADT, no PM1a block, no SMI_CMD, no I/O APIC carrying the SCI, an SCI line shared with another row, or HW_REDUCED_ACPI.
   • On main such a machine still handed over its NVMe and NIC claims from the loader's list. On this branch its first claim waits 30 s and every claim of the boot is refused.
   • This is a fail-closed consequence of the accepted design, but it is recorded only in the PR body. issues/a-hardware-reduced-x86-machine-has-no-power-off-and-no-power-button.md covers power alone.
   • It needs an issues/ record with its evidence, owner and exit, per root CLAUDE.md.

4. Evidence: tests/images/acpicase.toml changed, and its metal row was not staged.

   • Dropping diskserver changes the image of acpi_server_death (tests/toyos.rs:700), a T14-only row. Its fileserver still lists the data role with no block service.
   • The guest rows on this image pass under QEMU (guests-merged.log). Nothing shows that the T14 boot still reaches its job and readback without the NVMe.
   • The staged T14 batch has only testcases and testcases-xhci-leave (metal/t14-request.txt).
   • Cheapest fix: add acpi_server_death (one acpicase boot) to the T14 run the orchestrator is already making, or explain why the change cannot affect it.

5. kernel/src/iommu/window.rs:87: false contract. Addresses::map is documented "never handed out before". For Identity that is not true: it answers phys for any call. The sentence belongs to the Window arm alone, so say so or drop it.

Suggestions

1. sdk/abi/src/acpi.rs:358: MAX_BRIDGE_WINDOWS = 8 is unmeasured. The old bound was 64. Exceeding it refuses the whole declaration, which on the T14 would refuse every claim on the bench.
   • Inference, not measured: Intel root _CRS lists commonly produce the sixteen-KiB legacy windows at 0xc0000..0xdffff beside VGA and the 32- and 64-bit windows, which would exceed 8.
   • Raising the bound costs 16 bytes per window per bridge. The staged acpi_tables_loaded row will show the real count either way.
2. kernel/src/pcidev/mod.rs:417: the kernel keeps first_bus and drops last_bus. Lifecycle 2 will need the range, and it is easier to validate once at this boundary now: refuse overlapping ranges on one segment.
3. Lost coverage. The acpi_mediated probe's HeldFunction arm now checks the kernel-driven branch of pcidev::enumerated (:512). Nothing booted exercises the claim-held branch (f.held) any more, and only acpi_mediated checks HeldFunction in a guest. The PR body should say so, and if it can be restored cheaply, it should be. One way: a probe arm that declares q35's measured windows itself as the claim's holder, then holds an edu.
4. amdvi/selftest.rs:44, smmu/selftest.rs:62: the comment "the unit translates past the CPU's addresses" is an unchecked premise behind passing &[]. An assert! costs as little and holds it.
5. Kernel stall at boot (inference). The supervisor blocks inside its first PCI claim until acpiserver declares. On the T14, earlier namespace initialisation asked for about 10 s of sleeps (The AML interpreter finished to ACPI 6.5: Load and _OSC, the namespace initialised, every address space, every event, and the bounds stated #875), and the staged acpi_tables_loaded row prints each claim's wait. The orchestrator should read that row as a boot-time cost, not only as a pass.

Evidence checked

• ci-host-4.log: --ci host at 4f5142fea, EXIT=0, "86 step(s), all green". The FAILED lines in it are the proclife mutation controls reaching their verdicts.
• guests-merged.log: 18 passed at 4f5142fea.
• x86-undeclared-2.log: at d84d8c345, "waited 30006ms", and both edu claims refused by name. The test's lower bound of 30 s is a deadline that cannot fire early, so it is not a QEMU timing claim. The ceiling is three times the deadline.
• arm-cargo-run-final.log: _OSC: native hot-plug granted, the declared windows 0x10000000..0x3eff0000 and 0x8000000000..0x10000000000, "waited 5ms", 00:02.0, 00:03.0, 00:05.0 and 00:06.0 handed over, diskserver: partition … at block 256, vdagent: port 1 open, and domain1 "maps each pool at identity". The closed issue's exit is met.
• Controls: _TRA, the RAM fence, a second declaration replacing the first, and the claim not waiting are each red as stated, at revisions whose later edits do not touch the mutated lines.
• The _CRS reader handles Word, DWord, QWord and Extended descriptors, skips zero-length ranges, refuses _TRA, consumed, unknown and second-bus descriptors, and is swept over both QEMU _CRS lists.
• _OSC uses UUID 33DB4D5B-…, revision 1 and three DWORDs. The Control field is masked to what was asked, then to what was offered. Failure, an unrecognised UUID or revision, an absent _OSC and malformed answers are each host-tested.
• The judges are restated as claimed: clear_of_host_bridges (identity mappings at phys, outside every declared window, with red cases) and amdvi_translates (exactly one mapping, at identity).
• PR body correction (orchestrator's): the measured diff against origin/main is 69 files, +1940/−1113, not "+1621/−1100 over 67 files".

SEND BACK: required items 1 to 5. The T14 and AMD rows remain the orchestrator's to judge.

[Japabu]

Round 1 at de8e9883a (main 3b77b9b2f merged). Evidence: pr-935 64646e491, stage-b/round2/README.md.

1. Malformed records: toyos_pci::aperture::records checks every record before a window is read. It refuses a count or window run past its array, an unnamed _OSC word or a grant beside no answer, a reversed bus range, and two roots of one segment sharing a bus (your suggestion 2). The kernel keeps both bus ends. The refusal goes through Held::refuse: it is logged, the waiters are woken, and it stands as the answer, so a later declaration is late. Host-tested per field. The control that leaves the state Unknown reds the test.
2. _OSC: a query alone, revision 1, Control bits 0 and 4; the offer is recorded and logged as offered. Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934 commits. The osc header states this. A host test shows the firmware is called once, with the Query flag set; a control that commits reds it. QEMU q35's 0x1F and 0x1E masks are now cases.
3. Recorded as issues/an-x86-machine-with-no-acpi-row-hands-over-no-pci-claim.md, with each condition that leaves no row, the measured machines, owner and exit as ruled.
4. acpi_server_death: not staged. By the owner's ruling the branch is blocked on step 10 and no bench is re-staged before it. The body says the bench boots would fail by design until then. This row joins the batch when the branch rebases.
5. window.rs:87: gone with option 1, which the owner withdrew. window.rs is main's again, the one rule. Claims pass their declaration; kernel drivers, which come up before any declaration, pass none.

Also in this round:

• Window bound: the AMD finding is fixed with one list of 64 windows across every root. An 18-window root is a host case, and a control with the old per-root bound reds it.
• Shared metal check: every metal boot now fails on pcidev: the root bridges' memory is refused as declared, and the AMD row requires the declared-windows record.
• Lost coverage: your suggestion 3 is stated in the body.
• Size: measured at 70 files, +1972/−1047.
• Not taken: suggestion 4 (the selftests pass None now, so the premise is the window rule's own refusal); suggestion 5 (no bench boot happens before step 10).

[Japabu]

a18b42b88: the per-root record carries the _OSC commit beside the offer, so #934 needs no ABI change.

• HostBridge gains commit/committed beside osc/offered (renamed from granted).
• HostBridge::commit() answers Some(None) where no commit was made, as in all of stage B. It answers Some(Some(bits)) for a commit that granted no more than was offered. It answers None for a commit beside no offer, bits not offered, or an unnamed word.
• toyos_pci::aperture::records refuses any of those cases by name (Refused::Record) with the whole declaration.
• The kernel keeps the commit with the root's record and logs …, buses 0x00..=0xff, no commit (or committed 0x…).
• acpiserver still sends the query alone and declares None for the commit. Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934 performs the commit beside the query in osc.rs and declares the committed bits.

Host tests: an offer with no commit decodes; a commit decodes beside an offer covering it; a commit beside no offer, beyond the offer, or under an unnamed word is none; records refuses a commit with no offer and accepts an offer with none. cargo run -- --ci host at a18b42b88: exit 0, 86 steps green (log). No guest row was rerun: the kernel's log line gained a trailing clause, and the two judges that read it match prefixes that still hold.

[Japabu]

Review of #935, round 2: pushed 4e32df68c, plus local e307e6060 and 3d6257080

I reviewed the pushed head 4e32df68c and the two local commits that are not pushed yet:

• e307e6060 removes acpi_server_death's T14 registration.
• 3d6257080 merges main d7f269dbc (boot: the kernel hands the supervisor its images and parses no filesystem #994, kernel: a process is asked to quit, and one that never listens is killed #995, libc says what is true: no handler it never calls, an exclusive /tmp create, one link, real error texts #1001 and std, libc: a contended allocation sleeps on a futex instead of spinning #1007).

Against origin/main at 3d6257080 the diff is 81 files, +2243/−1197. Tests account for about +350/−240 of it, outside the inline unit tests. The main deletions are the loader's GCD and root-bridge readers, PciRootBridgeIo, KernelArgs' window array and its tests, and the OVMF Configuration() fixture with its sweep. The sweep moved to acpiserver over the evaluated q35 and virt _CRS lists.

Architecture

The ownership is right and matches #916's ruling:

• AML stays in acpiserver.
• The kernel holds one write-once aperture::Held. Its records refuse a malformed record by name and the refusal stands as the answer (round 1's item 1).
• The loader asks UEFI nothing about apertures.
• toyos-abi carries only the declaration that crosses the kernel boundary.

Over main's K1 allocator, the IOMMU change is the smallest that fits:

• Domains::reserved holds only the backend's own ranges: RMRRs, IVMDs, the interrupt range, AMD-Vi's special range and the ITS doorbell.
• Each OwnSpace::create passes the declared windows.
• No declaration means no domain.

The supervisor's ranking puts the acpi holder first and #962's disk drivers next, which is the order the wait needs. The aarch64 hardware-reduced claim is new kernel surface. It is justified, because acpiserver must run on virt to declare there, and it grants nothing beyond ECAM and firmware memory through the direct map.

The open owner decision is recorded honestly. The PR body and issues/an-aarch64-cargo-run-boot-hands-over-no-pci-claim.md say:

• the kernel's virtio console gets no domain before the declaration;
• VT-d falls back to identity;
• the SMMUv3 aborts the console's stream, so cargo run -- --arch aarch64 panics in wait_used;
• option 1 was withdrawn on a premise that turned out false.

I have not decided it. Landing waits on it whatever else is fixed.

I checked the stale-reference sweep after the deletions:

• No gcd.rs, rootbridge, root_bridge_windows, PciRootBridgeIo, #872, #865 or the-gcd-maps reference remains.
• One #870 remains, in a ruling's provenance line in the ACPI track.
• One rootbridge.rs remains, in a landed stage of the loader track.

Both are history and correct as they stand.

The repointed scheduler issues name issues/placement-has-no-migration-cost-or-wake-affinity.md, which exists on main. placement.rs and no-boot-reaches-the-retry… stay deleted.

Required

1. kernel/src/iommu/mod.rs:169-174, kernel/src/drivers/virtio_console.rs:235-238: false comments.

   • DeviceSpace::create calls unit::domain::create(0, None), which always fails with Undeclared or NoUnit, so DeviceSpace::Own is never built at this head.
   • The doc still says a kernel driver gets the machine's addresses only "where the unit has no room above the CPU's addresses". That is the rule K1 removed.
   • The console's comment says "an address space of this device's own, holding one pool".
   • Whichever option the owner picks, these must say what the code does. If option 3 or 4 is chosen, the dead Own path in create goes too.

2. e307e6060: acpi_release is now dead code.

   • The commit deletes the judge and its helper, and restoring them "from the tree before PCI root bridges are acpiserver's declaration: each root's _CRS windows and _OSC offer, held by the kernel; the loader's window reads go (PCI apertures stage B) #935" is the issue's exit.
   • It keeps tests/guest/rust-tests/src/bin/acpi_release.rs, which no image and no row runs. tests/toyos.rs:188 lists it in RUST_SKIP with a paragraph explaining why nothing runs it.
   • Delete the binary and its skip entry with the judge, and let the issue's exit restore both.
   • acpi_mediated.rs:352's "as acpi_release's" then needs rewording.

3. issues/an-aarch64-cargo-run-boot-hands-over-no-pci-claim.md:20-21: a misleading record.

   • "the console works, isolated by no domain of its own as it was on main" reads as if main gave it no domain either.
   • The PR body says the opposite, which is correct: main built the console a domain clear of the loader's list.
   • Say it loses the domain main gave it.

4. Evidence at the head that will land.

   • 3d6257080 merges boot: the kernel hands the supervisor its images and parses no filesystem #994. That merge rewrites KernelArgs (504 bytes, root_image at 184), the loader's start_kernel and the supervisor's start path, and this branch's start_service was resolved against main's new spawn.
   • Only ci-host-3 is running there. The 22 QEMU rows and both --build-only runs are at 1ffbdbaaf.
   • The cheapest sufficient check:
     • --ci host, plus --build-only on x86-64 and aarch64, at the pushed head;
     • the rows that boot through the supervisor's new order: a_drives_row_holds_one_process_per_function, a_claim_waits_out_an_undeclared_machine, acpi_mediated_access, virt_claim_lpi, and one usbd boot-stick row.
   • The metal at 4e32df68c predates boot: the kernel hands the supervisor its images and parses no filesystem #994's boot path. Rerun it only if those QEMU rows disagree with it; that is the orchestrator's call.

Suggestions

1. build/build.rs:3074: the test's scope is narrower than its claim.
   • It sees rows that drives or that start with a pci: device. It does not see a program that claims through the device syscap: virtclaimcase, testcases and metaldevicecase would pass it without acpiserver.
   • Either say so in its doc, or count device-syscap holders, with acpicase as a second exception.
2. sdk/abi/src/acpi.rs:357-360, system/acpiserver/src/apertures.rs:279: history in two doc comments.
   • "the per-root bound that refused it" and "the per-root bound of 8 that refused the AMD bench's root" are investigation history.
   • The bound's justification is the measured counts, and the AMD bench's is now 16 (metal/amd readback). State that number instead.
3. sdk/abi/src/acpi.rs:377: Osc::Offered's doc names "Stage B". Say "a query's offer", which stays true when Functions arrive and leave: the device set, native PCIe hot-plug, Gone (lifecycle stage 2) #934 commits.
4. system/supervisor/src/main.rs:963, 979: the declarer's late HOME is made in two places. One home step, taken where the session's home is made, would remove the second loop and the homes_made threading.
5. kernel/src/arch/aarch64/acpi_mode.rs:84 and x86_64/acpi_mode.rs:786: duplicated access code.
   • Both decode and validate an Access, make unaligned direct-map moves (Unaligned<T>) and make an ECAM config access.
   • None of that is architecture code. A generic module with arch hooks for ports and registers would keep one copy.
6. Owners named by PR number. the-acpi-servers-death-has-no-readback-on-the-t14.md and an-x86-machine-with-no-acpi-row-hands-over-no-pci-claim.md name "the PCI apertures track (PCI root bridges are acpiserver's declaration: each root's _CRS windows and _OSC offer, held by the kernel; the loader's window reads go (PCI apertures stage B) #935)", but no apertures track file exists, and the PR closes on landing. The ACPI track, which owns acpi_server_death's exit, is a lasting owner for the first.
7. Overlap with osbench and latency images run in ACPI mode, as a shipped image does #1009. Both PRs add acpiserver to benchcase and latencycase. Whichever lands second resolves the conflict. The supervisor ranks acpiserver first whatever the list order, so the two edits are compatible.

Evidence checked

• Metal, metal/amd/judge-b.log at 4e32df68c: 3 passed. The bench declares 16 windows in one root, and pcidev: a claim waited 21ms.
• Metal, metal/t14/testcases: verdict passed. The T14 declares 3 windows, a claim waited 67 ms, and the log reads _OSC: native hot-plug offered, buses 0x00..=0x79, no commit.
• Metal, metal/t14/acpicase: refused with no Boot: complete. That is the predicted outcome, and e307e6060's issue edit records it.
• ci-host-1.log at 1ffbdbaaf: EXIT=0, 87 steps green.
• I read every PCI root bridges are acpiserver's declaration: each root's _CRS windows and _OSC offer, held by the kernel; the loader's window reads go (PCI apertures stage B) #935 hunk against the merge base and traced:
  • answered(): the deadline returns Ok, the stall is withheld as Unanswered, and a kill is Unusable;
  • declare: records, then windows, then the RAM fence;
  • declarer_gone;
  • the _CRS reader's Word, DWord, QWord and Extended layouts, its bus rule, its _TRA rule and its consumer rule;
  • query_root's Support (bits 0 and 4) and Control (bits 0 and 4) fields, against PCI Firmware 3.3 Tables 4-4 and 4-5.

SEND BACK on items 1 to 4. The open owner decision blocks landing separately.

[Japabu]

Round 2 at f9e44e0fb (main d7f269dbc merged).

1. False comments: DeviceSpace::create's doc and the virtio console's comment now say what the code does: a driver in this kernel comes up before the declaration and keeps the machine's addresses. The owner's item 53 changes the code later.
2. acpi_release: gone with its row and judge, and out of RUST_SKIP. acpi_mediated.rs no longer names it. The issue's exit restores the job, the judge and the row, and no-t14-row-arranges-… now notes that the row is unregistered.
3. The aarch64 issue now says the console loses the domain main gives it.
4. Evidence at the head:
   • --ci host: exit 0, 93 steps green.
   • --build-only on x86-64 and aarch64: exit 0 each.
   • a_drives_row_holds_one_process_per_function, a_claim_waits_out_an_undeclared_machine, acpi_mediated_access, virt_claim_lpi and the_log_lands_on_the_boot_stick: 5 passed.
   • This found a defect from the boot: the kernel hands the supervisor its images and parses no filesystem #994 merge. At e6dd4addf, the_log_lands_on_the_boot_stick stalled waiting for usbd. boot: the kernel hands the supervisor its images and parses no filesystem #994 puts SYSTEM first in the service list, so taking the acpi holders from the list's front found none, and the disk drivers' claims waited out the declaration's deadline.
   • f9e44e0fb picks the holders out of the whole list. Its home step makes every holder's home, which also removes the [..at] half of suggestion 4.

Suggestions:

• Taken:
  • 1: the config test's doc says it does not see run-time device-syscap claims.
  • 2 and 3: the doc history is gone, and MAX_WINDOWS states the AMD bench's 16.
  • 6: both new issues are owned by the ACPI track.
• Not taken:
  • 5 (the shared access code): a refactor outside this PR's subject.
  • 7: whichever PR lands second resolves the overlap with osbench and latency images run in ACPI mode, as a shipped image does #1009.

The rows were checked against logs kept locally. Evidence publication waits on the owner.

[Japabu]

Review of #935, round 3, at f9e44e0fb

f9e44e0fb is pushed and merges cleanly with origin/main c2fa26319. Since 3d6257080 this round adds two commits:

• e6dd4addf, the round 2 answers;
• f9e44e0fb, the start-order fix.

Round 2 items

1. False comments: resolved.
   • DeviceSpace::create's doc now says what the code does. A driver in this kernel is given the machine's addresses, and no domain of its own, because it comes up before any declaration.
   • The virtio console's comment says the same and points at the aarch64 issue.
   • The unreachable Own arm in create stays until the owner decides item 53. Whether it goes depends on that decision.
2. acpi_release: resolved. The binary and its RUST_SKIP entry are deleted, and acpi_mediated.rs:352 no longer names it. The issue's exit now restores the row with both its job and its judge. no-t14-row-arranges-an-acpi-disable-asked-off-the-boot-processor.md now says that its row is unregistered, and why.
3. Aarch64 issue wording: resolved. It now says the console loses the domain main gives it.
4. Evidence at the merged head: resolved for host and QEMU. All of these ran at f9e44e0fb. The logs carry no revision line, but their timestamps (14:51–14:58) all fall after the commit (14:51:41) and before the next one:
   • r3-ci-host.log: EXIT=0, 93 steps green.
   • r3-build-x86.log and r3-build-arm.log: both EXIT=0.
   • r3-guests.log: 5 passed (a_drives_row_holds_one_process_per_function, acpi_mediated_access, virt_claim_lpi, the_log_lands_on_the_boot_stick, a_claim_waits_out_an_undeclared_machine, the last waiting 30006 ms).

Suggestions 1, 2, 3 and 6 are taken. The build test's doc states its scope, the two history comments state measured counts, Osc::Offered no longer names a stage, and both new issues name the ACPI track as owner.

The start-order fix (f9e44e0fb)

The defect was real:

• Since boot: the kernel hands the supervisor its images and parses no filesystem #994, self.services[0] is SYSTEM, which is started before the manifest is read.
• take_while(declares) therefore counted zero declarers, so drive_where(is_disk_driver) ran before acpiserver started.
• Each disk driver's claim would then wait out the 30 s deadline, and every claim of the boot would be refused.

The fix partitions the whole list into declarers and the rest, keeping their order, and is correct. I traced what it does to SYSTEM:

• SYSTEM is the first entry of the rest.
• is_storage holds for it, because it has a role, so it triggers no home making.
• start_service returns early for it, because child.is_some().

start_service's home loop now walks the whole list. That is correct, since every declarer is started before the first non-storage row.

The fix changes every metal boot's start order relative to the 4e32df68c readbacks, which predate #994's boot path. The metal re-run you plan after item 53 is required.

Suggestion

1. A guard for the start order. The order bug was caught by a QEMU row reaching the deadline, not by anything that names the order. A host test of the boot ranking would hold the invariant cheaply: every declarer is started before drive_where(is_disk_driver), wherever SYSTEM sits. Examples are undeclaredcase's refusal and the boot-stick row's 30 s. The boot logic is not host-tested today, so this is optional.

Verdict

No review blocker remains. Landing is still held by owner item 53 (aarch64 cargo run panics on its console's first queue) and by the metal re-run at the head that will land. Both are already planned.

LAND on the review's findings, once item 53 is answered and metal passes.