A claim hands each BAR over where firmware put it, in 4 KiB pages (Wi-Fi P1)

[Japabu]

P1 of issues/there-is-no-wifi.md, with its prerequisite, 4 KiB user leaves for device windows.

Problem

A claim moved every BAR it handed over onto a 2 MiB slot of its own, because 2 MiB pages were the only ones the kernel mapped into a process. That move is why the AMD bench's xHCI 03:00.4 (behind 00:08.1, whose window bus 3 fills) and the AX210 behind its root port could not be claimed, and it was what pcidev's placement machinery existed for.

Resulting behaviour

• User mappings take any run of 4 KiB-aligned pages (map_range, both arches): a 2 MiB leaf wherever a whole aligned frame lands on a 2 MiB boundary, a table of 4 KiB leaves for the rest. The choice is one pure function, toyos_userbound::leaves, host-tested. Unmapping a slot of 4 KiB leaves answers the table it unlinked (paging::Detached), which the caller drops inside its existing shootdown, since a sibling's paging-structure cache may still name it (SDM 3A §4.10.3); no extra shootdown is issued. x86-64 4 KiB leaves carry their own PAT bit (bit 7). Page-table ownership and the IOMMU domain layout are unchanged.
• A claimed function's BARs are mapped at their firmware addresses, in the 4 KiB pages they cover. publish records every memory BAR; a claim hands one over only where no other function decodes inside its pages and they lie in the declared root-bridge memory (toyos_pci::pages, host-tested). Otherwise the BAR is withheld by name (BarPages, BarUnrouted) and the function still handed over. The MSI-X table's page goes with its BAR; the kernel's remapping-entry rule (AMD-Vi stage 6: interrupt remapping, and claims only where every unit filters SMIs #921) is untouched, and tear-down masks the entry at the table address arming read.
• Bring-up chooses BARs before changing anything, then arms the interrupt last, so no refusal follows an armed message and the undo path is gone.
• Measured page sharing: every boot logs pcidev: N memory BAR(s), M of them sharing a 4096-byte page with another function or starting inside one. q35: 11 to 14 BARs by machine shape, 0 sharing (boots). Metal at 5f4418f: T14 21 BARs, AMD 14, 0 sharing (T14, AMD).
• msix-exclusive-bar=on is gone from build/qemu.rs and tests/common/qemu.rs: the NVMe guests drive QEMU's default controller through its table in BAR 0 (nvme_disk_boots and the diskserver boots green).

Deleted (measured)

40 files, +914 −2032 overall; kernel/lib/sdk/build +538 −1784. Gone: toyos_pci::placement (545 lines: free runs, reservations, behind_bridges), toyos_pci::probe (the "answers its own value" proof), toyos_pci::bridge (the bridge walk, 291), bar::placement, PciDevice::bridge/forwarded, and in pcidev place_bar(s), Source/Candidate, give_back, cut_already/was_cut/cut, alone_in_its_page, probe_dword, the 2 MiB runs and slot records (pcidev −620 +164), and the refusals only they raised; the x86 AddressSpace::pages map nothing wrote (#940 deletes it too, merged with main c0b1547).

Decisions

• Unassigned BARs: none is assigned. Main had no path that did (place_bar refused BarUnassigned), and the hot-plugged endpoint that needs one is lifecycle stage 2's (wt/toyos-lifecycle-2), whose place_unassigned will need rewriting onto this: a small assignment inside the port's window, no probe.
• Stage 3 of the process-memory track beyond device windows is not taken: device leaves own no frame, so no OWNED ledger or per-process count is needed, and a BAR's pages are in physical order, so a typed value straddling two of them is still one run (object_run's one-segment store and window_split's bound hold). What remains of stage 3 — the ledger, demand-zero stacks, 4 KiB TLS, straddle segments, the T14 floor — is restated in the issue.

What temporarily stops working

Nothing measured.

Bench round 1 (5f4418f, run by the orchestrator)

T14 3/3 PASS. AMD 2/3: amdvi_translates_the_stick_controller and msix_table_read_in_place PASS, and the first claim behind a bridge on metal handed 03:00.4's BAR 0 over in place (0xd0100000..0xd0200000) and usbd drove it. amdvi_usbd_drives_its_own_entry was red in end_returns_claims, which chose 1022:1639 by id on a bench that has two; it now chooses the spare as usbd_spare does and claims it by arrival (dc18514). Readbacks, judges and manifests: bench.

Review round 1

Fixed the two comment blockers (AArch64 Tables' ownership, survey's doc and unrouted line), took the shootdown suggestion above, dropped bar_map_behind_a_bridge's by-construction address comparison (the job's register read through the BAR behind the port is the claim), recorded P1's T14 NVMe exit as an Identify Controller completing through the in-place entry, recorded that P1's rows need no metal-row naming first, added the place_unassigned rewrite and Machine::decoded to lifecycle stage 2, and the nits. Declined: keeping Pages in Bound (one rounding helper, no defect), and refusing a claim whose MSI-X table BAR is unrouted (pre-existing; recorded nowhere new). All four bench images re-staged, since the unmap change is in every kernel.

Tests and evidence (ToyOSOrg/evidence pr-947, README)

• Host: cargo run -- --ci host, exit 0, 86 steps, at ecab334 (log); earlier at 3ef1e64 (log). New host tests: toyos_pci::pages (in place, sub-page BAR, page sharing refused, off-page, wrap) and toyos_userbound::leaves (device windows on and off a 2 MiB boundary, whole frames, misaligned runs); segment test notes the straddle-in-one-run case.
• Builds: --build-only x86-64 and aarch64, exit 0 at ecab334 (x86, a64) and at 3ef1e64 (x86, a64).
• QEMU at ecab334: 11/11 claim rows exit 0 (log), the nine below plus usbd_refused_without_smi_filter and usbd_refused_without_amdvi_remapping. At 3ef1e64, 9/9 exit 0 (log): usbd_drives_the_spare, bar_map_again (now also runs msix_in_place: the NIC's armed MSI-X entry read back through its holder's mapping of BAR 1's table page equals what the kernel logged writing), bar_map_behind_a_bridge (rewritten: was "BAR placed inside the port's window"; now the NIC behind the port is handed a BAR in place and the job reads its register through it), lent_device_memory_refused, a_drives_row_holds_one_process_per_function, the_compositor_drives_the_virtio_gpu, iommu_virtio_platform, virt_claim_lpi, nvme_disk_boots. No row deleted. An earlier red run (log) found bar_map_again reading the NIC's first BAR, which is now BAR 1 (the table, withheld before because it read zero at the probe dword); the job names BAR 4.
• Negative controls (log, r2): the page-sharing check narrowed to the BAR's own bytes reds a_page_another_function_decodes_in_is_refused_by_name; a short 2 MiB-aligned window mapped as a 2 MiB leaf reds two leaf tests; both restored green. The "ledger" control the brief named has no subject: no ledger was built (above).
• Metal, re-staged at ecab334 (T14, AMD); first staging (T14, AMD): T14 usbd_drives_the_type_c_controller, claim_reuses_its_remapping_entry, new msix_table_read_in_place (AX210 and NVMe entries at BAR 0 + 0x2000 read through their holders' mappings); AMD amdvi_usbd_drives_its_own_entry (restored with its judge from c648c14), amdvi_translates_the_stick_controller, msix_table_read_in_place (the AX200 behind 00:02.2).

Issues

Closed: a-bar-behind-a-bridge-with-no-free-2-mib-of-its-windows-is-not-handed-over, no-boot-reaches-the-retry-that-undoes-a-placement-nothing-answered. Rewritten: P1 in there-is-no-wifi (built; bench exits owed; the T14 NVMe driven through its table stays owed, the disk being another system's), nothing-reds-when-the-bar-survey-drops-an-assigned-bar, no-boot-reaches-the-refusal-that-keeps-a-bar-read-inside-a-declared-window, process-memory-is-2-mib-pages... (device windows done, stage 3 remains), and citations in four others.

Risks

• First 4 KiB user leaves on real hardware: PAT bit 7 on x86 (UC devices use PCD|PWT, so bit 7 is unused for them), and freeing a leaf table after its shootdown. Only the metal runs read either.
• The AMD row is the first claim behind a bridge on metal.

🤖 Generated with Claude Code

[Japabu]

Review of #947 at 5f4418f37 (Wi-Fi P1: BARs in place, in 4 KiB pages)

Architectural assessment

This is the right simplification. A BAR stays where firmware put it, and that removes the job the whole placement subsystem existed for: free runs, reservations, the bridge walk, the "answers its own value" probe, give_back, the slot records, and the undo path in bring_up. Ownership is clear:

• toyos_userbound::leaves is one pure decision that both architectures' map_range use.
• toyos_pci::pages::of_bar is the pure page/sharing rule.
• pcidev keeps only what the kernel must do: record firmware's BARs, refuse a claim without a declaration, map, and arm MSI-X.

No new ABI. No toyos-abi misuse (sdk/abi/src/pci.rs loses one stale clause). Leaving process-memory stage 3 untaken is justified: device leaves own no frames, and a BAR's pages are in physical order. The issue now says so accurately.

Line counts, measured with git diff --shortstat origin/main...HEAD:

• kernel/lib/sdk/build: +538 −1784
• tests: +306 −60
• issues: +70 −188
• total: +914 −2032, which matches the PR body.

Checked and correct

1. 4 KiB user mappings

• Leaf choice. leaves (lib/userbound/src/leaves.rs:18-34) asserts that va is 2 MiB-aligned. A slot becomes a Block only when pa + offset is 2 MiB-aligned and the slot is a whole 2 MiB. So:
  • A run starting off a 2 MiB boundary is pages in every slot.
  • A run ending mid-frame has a pages tail.
  • A short run that is 2 MiB-aligned is pages. This is the negative-control case, and the guest also hits it: 01:00.0's BAR 1 is 4 KiB at 0x80000000 in guests3.log.
  • BARs of 2 MiB or more are size-aligned powers of two, so they are always Block.
• Crossing 1 GiB. On AArch64 each slot calls tables.directory(va), and on x86 each slot calls ensure_table(va), so a run crossing a 1 GiB boundary builds its own directory.
• Table ownership. Unchanged: both children Vecs.
• Unmap ordering, x86 (kernel/src/arch/x86_64/paging.rs:589-600):
  • PDE cleared and discharged locally.
  • Futex revocation.
  • shootdown(User). This returns only once every CPU has flushed, using INVPCID type 3 or a CR3 reload, both of which invalidate paging-structure caches (SDM 3A §4.10.4.1).
  • Only then children.retain frees the table.
• Unmap ordering, AArch64 (kernel/src/arch/aarch64/paging.rs:476-489):
  • set(i, 0).
  • tlbi! brackets the invalidation as dsb ishst; tlbi aside1is; dsb ish; isb.
  • Only then the table is freed.
• Shootdown under the address-space lock. Safe: Lock's spin calls tlb::poll().
• Cache attributes.
  • x86 UC is PCD|PWT at both levels (PAT index 3). WC moves its PAT bit from 12 to 7 at 4 KiB (pte_bits).
  • AArch64 typed() is the same at L2 and L3. User and kernel device mappings are both Device, and both UC on x86.
  • policy_at now decodes 4 KiB leaves instead of asserting Normal.
• Kernel copies through a user pointer into a BAR. Still refused: FramePins::pin(.., Pmm) on x86, and through_direct_map on AArch64.
• Callers of alloc_and_map. RAM callers all pass multiples of 2 MiB (PageAlloc, PIPE_SIZE, align_2m in shm/vm), so RAM mappings are unchanged.

2. BARs in place

• Which BARs are recorded. publish records BARs only where memory_bar decodes. Unassigned (address 0) and I/O BARs are excluded. Prefetchable and 64-bit BARs are included, stepped as two slots.
• Zero size. advertised_size never answers Ok(0), so of_bar's bytes > 0 assert cannot be reached by a device.
• Sharing check. It covers every recorded memory BAR of every other requester: bridges' own BARs (bar_slots = 2) and kernel-driven functions included. Bridge windows have 1 MiB granularity, so a page never straddles two of them.
• Root-window check. aperture::decode runs on the rounded pages.
• Declaration state. Unknown and Refused refuse the claim before held is taken (claim, pcidev/mod.rs:736-748).
• A withheld BAR. It answers InvalidArgument from bar_object, and bar_bytes[i] = 0 in the description. Each consumer then refuses by name: diskserver's bar_bytes <= DOORBELLS, and usbd's map_bar(0, 0). The function is still isolated in its domain, so handing it over without that BAR is safe.
• Order in bring_up.
  • function_space is reused per function, as before.
  • bars() only reads.
  • enable_memory_space, then claim_msi, then arm.
  • Every refusal after claim_msi drops message before any entry is written.
  • No state survives that the old code did not also leave (memory decode on, the per-function domain).
• Tear-down. It masks at the table address that arming read.

3. Deletions.

• No code residue: grep over kernel, sdk, lib, build, tests and system for place_bar, alone_in_its_page, placement::, behind_bridges, probe_dword, MsixAt, msix-exclusive-bar, was_cut and cut_already finds nothing. The give_back hits are unrelated.
• LEND_WINDOW stays. It is the IOVA lend window for DMA grants, not a BAR slot, and its arithmetic (pcidev/mod.rs:299-301) is untouched.
• Nothing references the deleted issue paths.

4. Tests and evidence

• The nine QEMU rows. Run at 3ef1e64c9. git diff --stat 3ef1e64c9 5f4418f37 equals git diff --stat 3b77b9b2f 979d4c539: three files, tcp conn.rs/rx.rs and one deleted issue. Nothing the claim rows judge.
• Restored AMD row. amdvi_usbd and its row match c648c1439.
• msix_in_place. It establishes something independent: the device's own table answers, through the holder's mapping, the address and data the kernel logged writing. In guests3.log, 00:03.0 BAR 1 + 0 reads 0xfee00098.
• Negative controls. Both are real and named: the patch, red (exit 101 on the named test), reverted, green.
• Host log. ci-host3.log ends Host: 86 step(s), all green, exit 0. The evidence checkout path is masked at the tip ($WORKTREE, $HOME).

Findings

BLOCKER

• kernel/src/arch/aarch64/paging.rs:170: the comment "A root and every table under it, owned together and freed together" is now false. unmap (line 489) frees one child table on its own. Fix: state the actual contract, e.g. "freed with the space, or by unmap once its ASID is flushed", or drop the second half.
• kernel/src/pcidev/mod.rs:585-586: the survey doc says it "says the answer once and counts nothing from it", but the function now computes and logs withheld. Related: line 605's Unrouted message still says "no declaration to read it by". pcidev no longer reads BARs; the concern now is handing them over. Fix: delete or correct both phrases.

Both are comment-only. They can ride the #940 merge the branch needs anyway, and need no integration rerun.

SUGGESTION

• Second shootdown in x86 unmap (kernel/src/arch/x86_64/paging.rs:599): unmap now issues its own user-half shootdown for every slot of 4 KiB leaves. It does this under the address-space lock, and the caller's Unmapped drop then issues another. Unmapped already models "cleared but reachable until shot down". Handing the freed table to that value would keep one mechanism and one shootdown. Correct as written; this only removes duplication and cost.
• bar_map_behind_a_bridge comparison (tests/toyos.rs:4649-4686): comparing the handed-over address with the bars=[ enumeration line is true by construction. bar_at is only ever assigned bar.base, and bars() already refuses BarMoved, so the two numbers are one register read twice. The test's real value is the job reading device_feature through BAR 4 behind the port. That part is exercised and is not trivial. Consider dropping the parse.
• Discarded of_bar result (kernel/src/pcidev/mod.rs:890 and lines 778 and 1297): bars() throws away of_bar's Pages, then rounds bar_bytes again with pages::PAGE in the claim log and in bar_object. Keeping the Pages in Bound would leave one rounding and one grain.
• Unrouted MSI-X table (kernel/src/pcidev/mod.rs:833-868): bring_up now knows each BAR's verdict before arming. If the MSI-X table's BAR is withheld BarUnrouted, the kernel's own arming write still goes to that address. This was already true before this PR, but refusing here is now one line.
• P1's NVMe exit has no path (issues/there-is-no-wifi.md): "the T14's NVMe driven through that table, which no row does" names no way to meet it. An Identify Controller admin command, with its completion delivered through the in-place MSI-X entry, drives the controller through its table without touching the other system's data.
• Records the deletion leaves stale: these are for the orchestrator, not a branch cleanup.
  • Lifecycle stage 2 (issues/a-device-function-is-driven-from-its-arrival-to-its-end.md:100, "BARs are placed inside its port's window") loses the mechanism it would have built on. Two facts are recorded only in the PR body: place_unassigned on wt/toyos-lifecycle-2 needs rewriting, and a hot-plugged function must also enter Machine::decoded for the sharing check to see it.
  • issues/an-aarch64-cargo-run-boot-hands-over-no-pci-claim.md:34 still says "The windows placement offers".
• Metal-rows rule: the Wi-Fi track's "Metal rows" rule makes every stage with a T14 or AMD row depend first on a-metal-row-names-no-hardware-and-a-bench-without-it-reds.md, which is open. P1 adds msix_table_read_in_place and restores amdvi_usbd_drives_its_own_entry. Record whether that dependency was waived, or that the rows run filtered per bench.
• Nits:
  • kernel/src/arch/x86_64/paging.rs:19: a const sits between use lines.
  • from_bits(pde, pat) names its argument pde but also takes PTEs.
  • tests/common/iommu.rs:56 states which mutation reds. That is inferred, not in the evidence.

PR description (orchestrator)

• "q35 (guests): 12 BARs, 0 sharing" is presented as measured, but no published log contains the memory BAR(s) line. guests3.log prints only judged lines. Link the line or label the number.
• The quoted log text leaves out "or starting inside one".
• Everything else checked true: the counts, the deletion list, the evidence links and revisions, the scope of the issue edits, and the risks.

Verdict

SEND BACK, for the two comment blockers alone. They are trivial and need no rerun. Once fixed, LAND is pending the six bench rows the orchestrator is judging. Those rows are the only reading of 4 KiB user leaves and table freeing on real hardware, and of the first claim behind a bridge on metal.