A claimed function is armed on the mechanism it publishes, and the arming says which case it refused

[Japabu]

pcidev::bring_up armed MSI-X and nothing else, so a function publishing no MSI-X capability was refused by name and its holder never ran. Every function this project had handed to a process was a virtio one, and every one of those has MSI-X — so the refusal had only ever been reached by virtio_net_no_msix's deliberate vectors=0.

The ThinkPad T14's onboard I219 at 00:1f.6 is not one of those. Measured, not assumed: /proc/interrupts names its interrupt IR-PCI-MSI-0000:00:1f.6 … enp0s31f6 and /sys/bus/pci/devices/0000:00:1f.6/msi_irqs/162 reads mode=msi.

The arming says which case it refused

PciDevice::enable_msix collapsed four outcomes into one None. Its caller therefore had to walk the capability list again to tell "publishes no table" from "publishes one this kernel could not arm", and the refusal it raised asserted a reason false on three of the four paths. It now answers Result<Mmio, Unarmed> (kernel/src/drivers/pci.rs:33-44):

• Unarmed::Absent — the function publishes no MSI-X capability.
• Unarmed::Unusable — it publishes one whose table this kernel could not reach (Msix::decode, the BIR, or the table address).
• Unarmed::Blocked — the unit refuses this function's message. enable_msi calls the same PciDevice::message, so MSI would carry the same refused message.

bring_up is one match over that and walks no capability list of its own — kernel/src/pcidev/mod.rs:489-496:

let armed = match pci.enable_msix(VECTORS[slot]) {
    Ok(entry) => Armed::Msix(entry),
    Err(Unarmed::Unusable) => return Err(Refusal::MsixUnusable),
    Err(Unarmed::Blocked) => return Err(Refusal::NoInterrupt),
    Err(Unarmed::Absent) => {
        pci.enable_msi(VECTORS[slot]).then_some(Armed::Msi).ok_or(Refusal::NoInterrupt)?
    }
};

• publishes MSI-X → armed on MSI-X, or refused MsixUnusable. Its table and PBA are in a BAR, and falling back to MSI would be arming a function whose table is a structure this kernel could not read; a holder that can write a table entry can point the device's write at any address the LAPIC decodes.
• publishes MSI only → armed on MSI. Its message is a word of configuration space, which has no write path from userland.
• neither → NoInterrupt, which is virtio_net_no_msix's refusal.

There is no else if publishes(msi::CAP_ID) arm any more, and no closure re-deriving what the arming already knew. enable_msi opens by looking its capability up and answers false without one (kernel/src/drivers/pci.rs:324-326), so that arm decided nothing: deleting it moved no log line on any machine, and no test in any tier could have seen it. The test that sees the surviving structure is virtio_net_no_msix (tests/common/faults.rs:281-283, Fast): it takes the Absent arm, reads enable_msi's false back, and requires neither its MSI-X nor its MSI could be armed.

Refusal::MsixUnusable says only what is true on every path it fires on. It used to say the table "is in a BAR nothing here can name to withhold", which holds only where Msix::decode failed — after a successful decode msix_bar answers Some(bir) and place_bars withholds that BAR (kernel/src/pcidev/mod.rs:539). The message() path is split off entirely: it is NoInterrupt now, because enable_msi fails identically there, and the console had already printed PCI …: not armed — {why} one line above the old contradiction.

PciDevice::capability(id) (kernel/src/drivers/pci.rs:363-366) is the one spelling of "find this function's capability by id", replacing seven copies of capabilities().find(|c| c.id() == …): the four in drivers/pci.rs, msix_bar and reset in pcidev/mod.rs, and power_up in drivers/hda.rs.

That hand-over rule is stated once, in the module whose subject line is a function driven by a process (kernel/src/pcidev/mod.rs:1,18-23). The kernel's own xHCI (kernel/src/drivers/xhci/wait/boot.rs:101-105) and HDA (kernel/src/drivers/hda.rs:664-668) drivers arm MSI-X or fall back to MSI, and that is not the same choice under a contradicting rule: nothing is handed over there, so no BAR carrying a table ever reaches a holder. Both, and virtio_sound::arm_interrupt, move from .is_some()/.is_none() to .is_ok()/.is_err() and decide nothing new.

Bound holds whichever mechanism was armed. The driver above the boundary cannot tell which it got and does not have to: both deliver the same vector into the same Interrupt and the claim answers the same handle either way. disable_msi is the enable bit alone.

Size, measured

git diff origin/main HEAD --numstat -- kernel toyos-pci tests userland is +111 / −61; git diff origin/main HEAD --shortstat over the whole diff is 12 files changed, 194 insertions(+), 104 deletions(-). toyos-pci/src/lib.rs and userland/netd/src/virtio_net.rs are byte-identical to origin/main (git diff origin/main HEAD -- <path> empty). tests/common/iommu.rs is not, and an earlier revision of this body said it was: git diff origin/main HEAD --shortstat -- tests/common/iommu.rs is 1 file changed, 1 insertion(+), 6 deletions(-), the six-line BAR_MOVED/MSIX_ARMED doc cut to its one contract clause.

The two checks

Negative control — the whole change reverted onto the base the green arm was measured on. Every implementation line this branch adds is in kernel/ and toyos-pci/; tests/common/faults.rs's one changed assertion is the only test change. So the control is exactly:

git checkout origin/main -- kernel toyos-pci
cargo test --test toyos-build -- virtio_net_no_msix     # expected: red
git checkout HEAD -- kernel toyos-pci

The base kernel prints its MSI-X could not be armed; the arm requires neither its MSI-X nor its MSI could be armed.

What it measures, and what it does not. It reverts the whole implementation and is red on the base, which is the rule. What it discriminates is the refusal string: the MSI arm, Unarmed's three cases, MsixUnusable and both disable_msi sites are reverted by it and every arm stays green. That hole is issues/kernel/nothing-reaches-the-msi-arm-of-a-claimed-function.md, not a claim of coverage made here.

This control has not been run, and neither have the four guest arms. Every cargo test --test toyos-build invocation in this worktree is refused before it builds, because the machine-wide sysroot is claimed by another checkout for an ABI change that is not on main yet:

$ cargo test --test toyos-build -- virtio_net_no_msix
thread 'main' panicked at src/toolchain.rs:1382:29:
this worktree and the shared sysroot at /Users/jan/Dev/jan/toyos/rust disagree about toyos-abi/src…
the sysroot belongs to /Users/jan/Dev/jan/toyos-aperture (branch wt/toyos-aperture)…
**Wait for it to land and merge main.** This refusal then ends by itself.
Do not pass --claim-sysroot.
EXIT=101

That refusal names --claim-sysroot as the thing not to do, so it was not done, main was not merged in, and no workaround was attempted. The four guest arms run on CI for this PR regardless; the control above is one command and is owed before this lands.

Independent oracle — Linux's own reading of this exact function on this exact machine: IR-PCI-MSI-0000:00:1f.6 … enp0s31f6 and msi_irqs/162 mode=msi, a differential implementation nobody here wrote, saying 00:1f.6 is an MSI part. Beside it, the capability's register layout is the PCI spec's and toyos-pci/src/msi.rs's tests encode it: address, data and mask offsets all move with the 64-bit address bit, and a vector written at the wrong one lands in whatever capability comes next in the list.

What the bench has measured, and what it has not

Two T14 runs, on different bases — run 28 is tip=220305b4 (t14-run28/lancase.log:1), run 29 is tip=24625c6b (t14-run29/lancase.log:1), whose parents are 938957ae and 8dec3ec8, and 938957ae ("The address the loop pings is the claimed function's, not the machine's name") is in one and not the other. The pair is therefore not a negative control and a green arm; it is two measurements.

• Run 28 (t14-run28/lancase.log:352, 1.349 s): pcidev: PCI 00:1f.6 NOT HANDED OVER — its MSI-X could not be armed…; netd exited code=0 at 2.268 s (:370).
• Run 29 (t14-run29/lancase.log:352-353, 1.445 s): iommu: irte5 source=00:1f.6 … vector=0x28 and PCI 00:1f.6: msi address=0xfee000b8 data=0x00000000 — MSI armed all the way to the message, on real hardware. Then :354: pcidev: PCI 00:1f.6 NOT HANDED OVER — this machine has no 2 MiB-aligned address space above what firmware assigned to put a BAR in; netd exited code=0 at 2.521 s (:372).

So the claim is still refused and the cable is still dark: this change moved the refusal from NoInterrupt to NoWindow, and no interrupt has been delivered on MSI yet. The stacked 32-bit-window branch is what the next gate needs.

Sentences in this branch's record that are false, retracted by name

History is not rewritten here, so each retraction is a later message.

Commit 8dec3ec8 — "nothing answered on the cable for the twenty seconds the boot stayed up", contradicted by t14-run28/lancase.log:12; and "Run 28 on the T14 is this change reverted whole, on the base the granted claim will be measured against", contradicted by the two tips above. Both retracted in 76fb456d's message.

Commit 76fb456d — its message attributed "five sites" to grep -rn 'disable_msi\b\|enable_msi\b' kernel/. Re-run, that command prints seven lines: the two definitions plus five call sites. The enumeration that followed it was of the call sites and is right. Its body also cited the choice at mod.rs:487-496, which was the comment above the block and one line short of it. Both retracted in 6d59a093's message, and this body carries the corrected numbers.

What this leaves standing, and to whom

Recorded in issues/ with ownership, evidence and an exit condition — not in this body:

• issues/kernel/nothing-reaches-the-msi-arm-of-a-claimed-function.md — no test in any tier arms a claimed function on MSI. virtio_net_no_msix calls enable_msi from bring_up and reads false back; nothing reaches a true, so nothing reaches disable_msi from either hand-back site, Armed::Msi's teardown, Refusal::MsixUnusable or Unarmed::Blocked. The two pre-existing MSI armings (xHCI's at boot.rs:104 and HDA's at hda.rs:666) never disarm, so MSI teardown is exercised nowhere in the tree. Owned by the network track's stage-2 I219 worker; the exit is the first userdev interrupt counted against a claim on 00:1f.6, plus netd exiting from that claim.
• issues/kernel/nothing-asserts-that-a-claim-answers-no-configuration-write.md — SYS_DEVICE_REG_WRITE on a RegTarget::PciConfig target is refused NotSupported and nothing reads that refusal, which is what a handed-over MSI function's safety rests on. The exit is a guest arm in which a holder calls it on its own claim, red against a kernel whose arm answers Ok.
• issues/hardware/toyos-i219-refuses-a-part-outside-msi-x-mode-at-ivar.md — toyos-i219 writes §10.2.4.9's IVAR and reads it back, that section defines the register only "in MSI-X mode", and 00:1f.6 is measured to be outside it. Owned by the stage-2 I219 worker. That is the half of the old tracker this branch does not remove, which is why the file is narrowed and renamed rather than deleted.

Green

Each row is the line the command printed and its exit status, run in this worktree at 6d59a093.

command	result	exit
cargo test -p toyos-pci	test result: ok. 40 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out	0
cargo test --lib	test result: ok. 295 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out	0
cargo test --workspace --exclude toyos-build	138 suites, 1347 passed, 0 failed, 0 ignored	0
cargo clippy --workspace --all-targets --keep-going -- $ADOPTED -D warnings	Finished dev profile, no warning	0
cargo clippy --target x86_64-unknown-none -- $ADOPTED -D warnings (in kernel)	no warning	0
cargo clippy --target x86_64-unknown-none --features boot-actuators,test-actuators -- $ADOPTED -D warnings (in kernel)	no warning	0
cargo clippy --target x86_64-unknown-uefi -- $ADOPTED -W clippy::undocumented_unsafe_blocks -D warnings (in bootloader)	no warning	0
cargo clippy -p toyos-abi --all-targets --keep-going -- -W clippy::undocumented_unsafe_blocks -D warnings	no warning	0
cargo test --test toyos-build -- virtio_net_no_msix (and the other three arms, and the negative control)	not run: the sysroot is claimed by /Users/jan/Dev/jan/toyos-aperture	101

All five src/clippy.rs shapes are above — the whole gate, not a subset. $ADOPTED is the workflow's six lints, spliced token by token as src/clippy.rs:14-20 declares them. cargo test -p toyos-pci is 40 here against 39 on origin/main: this branch adds disabling_clears_the_enable_bit_and_nothing_else and nothing else.

🤖 Generated with Claude Code