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

[Japabu]

A PCI function handed to a userland driver was armed on exactly one interrupt
mechanism: pcidev::bring_up called enable_msix(...).ok_or(Refusal::NoMsix)?,
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 so far 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 NIC is not one of those. Booted on the bench (run 28,
tip=220305b4), this kernel wrote, 1.349 s in, pcidev: PCI 00:1f.6 NOT HANDED OVER — its MSI-X could not be armed, and a claim with no interrupt is a driver that would never be told anything; netd found no endowment and exited, and the
bench's one cable carried no ToyOS.

The owner's direction of 2026-09-08 is the rule this implements: the LAN
uses the most modern interrupt mechanism the device offers and never INTx.
MSI-X first wherever a function has it; MSI only where it has none — the T14's
I219 publishes no MSI-X capability, so there MSI is the most modern there is.
INTx is never armed, and nothing in this branch adds a path that could arm one.

What the kernel does now

bring_up is one match over what the arming answered, and it walks no
capability list of its own:

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::NoTable(NoCapability::Truncated)) => return Err(Refusal::CapsTruncated),
    Err(Unarmed::NoTable(NoCapability::Absent)) => {
        pci.enable_msi(VECTORS[slot]).then_some(Armed::Msi).ok_or(Refusal::NoInterrupt)?
    }
};

enable_msix answers Result<Mmio, Unarmed> and splits the three ways it can
fail where each is known, so no caller re-derives it and no refusal asserts a
reason false on the path that raised it:

• Unusable — a table this kernel could not reach: Msix::decode failed, the
  BIR is not a memory BAR, or table_address failed. Refusal::MsixUnusable
  says the function publishes MSI-X, this kernel could not arm it, and MSI is
  not a fallback for a function that has a table.
• Blocked — the unit refuses this function's message (iommu::remap_msi).
  enable_msi calls the same private message() with the same arguments and
  fails identically, so Refusal::NoInterrupt is exactly what happened.
• NoTable(Absent) — a walk that reached the capability list's terminator and
  found no MSI-X. This is the only case that reaches the MSI arm.
• NoTable(Truncated) — a walk that stopped at a link the PCI spec forbids.

Truncated is the security case, and it was the branch's own hole. The walk
is caps::CapWalk, which ends at a misaligned pointer, one below the standard
header, or one already visited. Until cad60ec6 a function whose MSI capability
preceded such a link and whose MSI-X capability followed it read as absent,
was armed on MSI, and msix_bar — the same blind walk — named no BAR, so
place_bars withheld none and the MSI-X table's BAR went to the holder with
everything else. A holder that can write that table points the device's message
at any address the LAPIC decodes. On the base that same function is refused
NoMsix and reaches no holder, so the regression was this branch's and is
closed in it.

PciDevice::capability(id) is the one spelling of "find this function's
capability by id". It replaced six copies of
capabilities().find(|c| c.id() == …), three of them in drivers/pci.rs;
grep -rn '\.capability(' kernel/src counts 8 callers today.

What the reviews changed

1. The truncation refusal is classified where the walk is already driven.
The branch had priced two holes as one. Arming a claimed function on MSI needs
silicon or a boot config; the Truncated/Absent split needs neither.
kernel/src/drivers/virtio.rs's cap_selftest already drove the real walk over
a cyclic list, a misaligned link, a below-header link and a forbidden head
through PciDevice::over_config, so each case now also reads back what the
walk's end made of a capability, and prints its own verdict line,
pci cap split. pci_capability_walk is Tier::Fast, so that half is on the
per-pull-request gate and cost no new registration at all.

2. The arming's own answer is read back, not only capability's. bring_up
matches on enable_msix, so each walk case now asserts device.enable_msix(0)
as well as device.capability(msix::CAP_ID). No layout there publishes an MSI-X
capability the walk reaches, so the call returns at its lookup and touches no
MMIO.

3. A case that both finds a capability and truncates, and holds a real table
past the forbidden link. Every layout published only PCI_CAP_ID_VENDOR, so
Ok(_) => "found" was unreachable and the split only ever separated absent from
truncated. The row is now
&[(0x40, msi::CAP_ID, 0x43), (0x44, msix::CAP_ID, 0)] — a capability the walk
reaches, a link the spec forbids, and an MSI-X capability past it. With only the
first tuple, capability(msix::CAP_ID) answered Truncated over a config space
holding no MSI-X capability anywhere, so the case could not tell a walk stopped
at the forbidden link from one that reached the end of a list with no table;
with the second, truncated means "there is one and it was not read", which is
the discrimination the refusal exists for. CASES stays 15 and SPLITS 13: the
row joins a case rather than adding one.

4. MSI-X first is asserted where a function actually publishes both.
tests/e1000case/system.toml hands netd pci:8086:10d3 — QEMU's e1000e,
which publishes MSI at 0xd0 and MSI-X at 0xa0 (read off the device model over
0xcf8/0xcfc at .github/qemu-version's 11.1.0) — and https_tls13_e1000e is
Tier::Fast. iommu::armed_on_msix takes the vendor:device the boot config
declares (Bench::claims) and requires msix address= for the slot that claim
is on while refusing msi address= there. Point 17 is where that slot stopped
being whichever one the guest printed.

5. A vacuous assertion is gone, for the second time.
pci_function_is_exclusive asserted must_not_say(MSI_ARMED) on 00:03.0,
whose capability list is MSI-X at 0x98 and five vendor capabilities — no id 0x05
anywhere — so no mutation of this kernel can print that line. 94341ce1 had
deleted the identical assertion from tests/common/iommu.rs for that reason and
it returned one file over. Its must_say(MSIX_ARMED) neighbour goes too: on a
function whose only armable mechanism is MSI-X a hand-over is the msix line,
and the handovers != 1 refusal above already requires one. MSI_ARMED is
deleted, and the msix address= line has one spelling — faults::msix_armed(),
read by the arm that requires it and by every judge that requires its absence
(point 17, which is where the second spelling of it was finally closed).

6. The refusals the deleted register carried are recorded again. 76fb456d
deleted pcidev's "What is read back, and what is not", and the two issue files
this branch filed recorded only the MSI arm and the configuration write.
issues/kernel/a-claims-own-refusals-are-read-by-nothing.md records the rest:
ClaimError::Ambiguous, KernelDriven and Exhausted, every window refusal,
and every bound SYS_DEVICE_BAR_MAP and SYS_DEVICE_DMA_ALLOC check.

7. kind: defect over a body saying nothing has ever run the write.
issues/hardware/toyos-i219-refuses-a-part-outside-msi-x-mode-at-ivar.md is a
finding; issues/README.md gives defect as "real, reproducible".

8. The kernel-driven fallback says once why it is safe.
hda::arm_interrupt and xhci::wait::boot::arm_interrupt still take MSI on
whatever a truncated walk reached. PciDevice::enable_msi's own doc is where
that is said, because it is the call both of them make: a driver in this kernel
hands no BAR of its function to a holder, so an MSI-X table past a forbidden
link is one nobody but this kernel could reach. Neither site restates it.

9. The truncation refusal has a judge, and the branch no longer carries a
privilege path a one-field mutation cannot see. Round 3 reported that
reverting bring_up's two NoTable arms left every tier green, and the tracker
priced the alternative at "a boot config carrying such a function and a test
binary to hold it, plus that boot's tier row and CI price". That price is wrong
twice: the arm under test is a refusal, so no holder is needed, and the
kernel's own actuator machinery reaches inside this arming path already.
pcidev-caps-truncated is one actuators! row; StagedCaps in
kernel/src/drivers/pci.rs holds one requester id across the hand-over's own
walks and CapabilityIter::next ends that function's list one byte off dword
alignment after its MSI capability, leaving every other walk in the machine
reading the list the device published. pci_claim_caps_truncated
(Tier::Fast, tests/common/faults.rs) boots tests/e1000case under it and
reads faults::refused_claim — the refusal on the known slot by its own reason,
neither msi address= nor msix address= for that function, no hand-over of
[8086:10d3], no BAR moved, init's refusal line — then netd's exit,
Boot: complete and a clean console. Mutation 1 below is the negative control
it was added with.

10. The vacuous assertion is deleted a third time, by ruling.
iommu::armed_on_msix was called from tls13_judge for both benches, so
must_not_say("PCI 00:03.0: msi address=") ran on every https_tls13 —
1af4:1041 publishes no id 0x05, so that arm is green on every implementation
of this kernel. It is the identical arm 94341ce1 deleted and eea8c7f7
deleted again, reinstated one call site further out. The orchestrator's round-4
ruling is that it is deleted and stays deleted. There is no must_not_say of an
msi address= in tests/common/https.rs at all now: tls13_judge answers the
boot console, and the https_tls13_e1000e registration — the one bench whose
claimed function publishes both mechanisms — makes the assertion.

11. Bench::claims is read against the file it names. It restated
tests/e1000case/system.toml's devices row in Rust, which is the drift
tests/common/devices.rs's the_config_runs_exactly_these_jobs exists to
prevent. every_bench_claims_what_its_config_declares follows that pattern: it
reads each bench's system.toml with toml::from_str, the parser
load_audio_baseline already reads tests/audio-baseline.toml with, indexes
programs.netd.devices — netcase declares the same function twice, once for
netd and once for the test binary that asks for a second claim — and asserts the
constant against that row.

What round 4 changed

12. One refused-claim judge, where there were three copies.
faults::claim_caps_truncated had been written beside two arms that already did
the job: virtio_net_no_msix and iommu::no_unit_is_no_claim each asserted the
refusal line, the reason, no hand-over, no BAR, init's line. refused_claim(log, claims, why) is that judge and all three call it, so a kernel that answered a
refusal by logging it and handing the function over anyway is red wherever the
refusal is reached. What stays at a caller is that arm's own: the argv check and
the audio function for the crippled NIC, the actuator's parameter for the
truncated list, and — on the machine with no unit — that nothing at all was
handed over, which is more than the claim's own refusal says.

13. The refused function's address is the harness's, never the guest's.
The judge read the BDF out of the console and then asserted about that, which
is an assertion about whichever function the kernel happened to name. It knows
the profile's slot (00:03.0), refuses a console that refused any other
function, and anchors each line to it: pcidev: PCI 00:03.0 NOT HANDED OVER — <reason> is one anchored match rather than two unanchored ones. The control
below shows it working — the base kernel refuses the same function with a
different reason and the anchored line reds on it.

14. One spelling of each thing the judge reads. NO_FUNCTION was declared
in kernel/src/drivers/pci.rs and again in kernel/src/iommu/vtd/fault.rs; it
is declared once now, where a function's address is a triple, and the fault
handler reads it through the import it already had. NETD_EXITS was declared
twice and is declared once. 1af4:1041 was written in three places and is read
from https::VIRTIO.claims, the constant point 11 holds against the committed
devices row. The two lines a hand-over spends are built by bar_moved and
msix_armed, so the arm requiring them and the arm requiring their absence
cannot drift apart. What this round missed is that iommu::armed_on_msix spelled
msix address= a third time, which is point 17.

15. Prose deleted, not moved. The escalation story — read the early end as a
terminator, MSI armed on the guess, msix_bar withholding no BAR — was told at
pcidev/mod.rs's header, at drivers/pci.rs's StagedCaps and again in the
judge's doc. The header keeps it and the other two are gone.

16. A compromise on the ordinary path is recorded. place_bars's
Some(index) == table_bar mutated to (Some(index) == table_bar && false) hands
the MSI-X table's own BAR to the holder of every function that publishes a table,
and https_tls13, https_tls13_e1000e, pci_function_is_exclusive and
userdev_dma_fault are each green on it — mutation 5 below, with the spelling
that builds and the bare false that does not. It is pre-existing:
place_bars's line is dc38a054's own, byte for byte, and this branch neither
wrote nor moved it. It is not fixed here — it is a bullet in
issues/kernel/a-claims-own-refusals-are-read-by-nothing.md, which this branch
created for exactly that list. A refused claim is not the arm that would cover
it; the refusal spends no BAR at all, so what is unread is the hand-over that
succeeds.

What round 5 changed

17. The MSI-X judge asserts the harness's address too. Point 13 applied
round 4's ruling to refused_claim and stopped one file over.
iommu::armed_on_msix still read the BDF out of the guest's own
[{claims}] handed over on slot line and then asserted msix address= and
msi address= for that, which is an assertion about whichever function the
kernel named — and it is the same third spelling of msix address= point 14
said there was one of. It reads faults::CLAIMED_AT now, asserts the printed
address equal to it, and spends faults::msix_armed() and the new
faults::msi_armed(); the older mechanism's line gets the constructor the newer
one already had, so neither is written in two places. Mutation 4 below is what
that buys: a kernel that arms MSI on the claimed function and names another
one in its hand-over line passed the old judge and reds on this one.

18. A text scan that cannot parse a line refuses instead of dropping it.
refused_claim's walk over NOT HANDED OVER lines was two filter_maps, so a
line carrying the marker without the pcidev: PCI prefix left the list
silently. The empty list already reds; what did not was a partial miss — one
refusal the scan can read on CLAIMED_AT and a second it cannot read at all,
which is exactly the console "refused any other function" exists to catch. A
text scan closes only the spellings it matches, so the unmatched one is now the
finding: faults::functions_named is that walk for both judges and answers an
Err naming the line and the marker.

19. Prose corrected where it is evidence. The issue file no longer counts
the refusals that are read back — this branch's own judge moved that count, so
it lists them instead. Its place_bars bullet spells the mutation in the form
that builds and names the four tests measured green on it rather than claiming
every tier. CLAIMED_AT's doc said "the slot every profile in this suite puts
the function netd claims on"; no profile puts it anywhere — the slot is QEMU's
assignment by -device order, git grep 'addr=' -- tests/common/qemu.rs prints
nothing, and Profile::Metal carries no such function at all — so it says what
is true of the constant: a wrong one reds and never passes. And the control
below cited toyos.rs:18383, which dc38a054's merge had moved onto a doc
comment; the refusal is assert_fast_profile_label at tests/toyos.rs:18399-18405.

Retracted by name

History is not rewritten here, so these are withdrawn rather than edited.

• 6d59a093's message and this body said PciDevice::capability replaced
  "seven copies of capabilities().find(|c| c.id() == …) — the four in
  drivers/pci.rs". Both halves are false.
  git grep -n 'capabilities()\.find' 8261079e -- kernel toyos-pci userland
  prints 6 lines, 3 of them in kernel/src/drivers/pci.rs; the other
  three are hda::power_up, pcidev::reset and pcidev::msix_bar. The seventh
  caller, disable_msi, is new code on this branch and replaced no copy.
• a2be5f84's message says "The five remaining readers of capability" and
  then names six.
• a2be5f84's message justified deleting userland/netd/src/i219.rs's BAR
  clause with "which this branch falsifies — the T14's 00:1f.6 publishes no
  MSI-X, so nothing is withheld from that claim". False. That clause is
  about code which runs on tests/e1000case too, where the claimed 8086:10d3
  does publish MSI-X with its table in BAR 3 — so the kernel does withhold that
  BAR and does report 0 bytes for it. The invariant returns as one clause at the
  site.
• This body, 68ba8df6's message and the round-2 handoff all said
  pci_function_is_exclusive's MSI-X-first assertion "cannot be shown by a
  mutation: no function this harness hands to a claim publishes both
  mechanisms". False. tests/e1000case hands one to a claim on the fast
  tier, and mutation 2 below is run against it.
• eea8c7f7's message and this body offered "-D dead-code refuses a kernel in
  which Refusal::CapsTruncated is never constructed" as what stood against the
  unwitnessed privilege arm. It is not a guard. The lint fires only on a
  mutation that keeps the variant while deleting its constructor; it fires on
  the mutation, never on a regression that reached main; and an #[allow]
  or any later arm that constructs the variant removes it silently. The whole
  change reverted — the arms collapsed and the variant deleted, which is the
  form CLAUDE.md's mutation rule asks for — builds clean, exit 0, and is
  mutation 1 below.
• issues/kernel/nothing-reaches-the-msi-arm-of-a-claimed-function.md priced a
  guest arm at "a boot config carrying such a function and a test binary to hold
  it". Refuted by this tree, and the file is corrected: the shape is staged
  on a function an existing boot config already hands to a claim, and a refusal
  needs no holder. What the file still tracks is the MSI arm that succeeds,
  which nothing in any tier reaches.
• This body's earlier counts were measured against ad61ed08 and then
  8261079e. Each measurement below names the head it was taken at, because
  this branch has had two since: every green row, mutations 1, 4 and 5 and the
  size numbers were run at 348ac77f, which this head (f0073d33) is one doc
  comment and no code away from; the negative control and mutations 2 and 3 are
  d82dff33's, the head before the merge of 9f91b581, and nothing that moved
  between the two is on a path any of them touches.

The two checks

Negative control — anchored by name to dc38a054, never to a relative
expression a merge moves. For every path the control reverts, dc38a054, the
earlier anchors 8261079e and ad61ed08, and main's tip as merged in this
head (9f91b581) all hold the same bytes:
git diff --name-only ad61ed08 dc38a054 -- <those paths> prints nothing, and
git diff --name-only dc38a054 9f91b581 prints .claude/agents/reviewer.md and
src/durations.rs — neither a reverted path nor a judge — so re-anchoring moves
no byte of what is reverted. It reverts the 16 non-judge paths this branch's
own commits touch and keeps the four judges —
tests/common/faults.rs, tests/common/https.rs, tests/common/iommu.rs,
tests/toyos.rs — plus tests/test-durations, which is not a judge but is the
price row tests/toyos.rs's registration requires (reverting it too makes the
harness refuse the run by name in assert_fast_profile_label,
tests/toyos.rs:18399-18405, instead of running either arm).
kernel/src/iommu/vtd/fault.rs joins the list this round: it reads
drivers/pci.rs's one NO_FUNCTION now, so a control that reverted the
declaration without it would not compile.

B=dc38a054
git checkout $B -- kernel/src/actuator.rs kernel/src/drivers/hda.rs \
  kernel/src/drivers/pci.rs kernel/src/drivers/virtio.rs \
  kernel/src/drivers/virtio_sound.rs kernel/src/drivers/xhci/wait/boot.rs \
  kernel/src/iommu/vtd/fault.rs kernel/src/pcidev/mod.rs \
  toyos-pci/src/caps.rs toyos-pci/src/msi.rs \
  userland/netd/src/i219.rs \
  issues/kernel/a-claimed-function-must-have-msi-x-and-the-i219-may-not.md
git rm -q issues/hardware/toyos-i219-refuses-a-part-outside-msi-x-mode-at-ivar.md \
  issues/kernel/a-claims-own-refusals-are-read-by-nothing.md \
  issues/kernel/nothing-asserts-that-a-claim-answers-no-configuration-write.md \
  issues/kernel/nothing-reaches-the-msi-arm-of-a-claimed-function.md
git diff --name-only $B          # the judges and the price row, or it is not a control

printed exactly

tests/common/faults.rs
tests/common/https.rs
tests/common/iommu.rs
tests/test-durations
tests/toyos.rs

Run at d82dff33, the control kernel builds — exit 0 — and two judges go
red, each the command's own exit status:

FAIL pci_capability_walk: not every crafted capability layout was answered: [kernel 0.128 cpu0] virtio: pci cap selftest 14/14
test result: FAILED. 0 passed, 1 failed, 0 stale or expired expected-failure entries, 0 invalidated, 1 total (12.9s)

exit 1 — and its ALONE line reads "red again on a DIFFERENT failure",
which is the harness comparing two strings that carry the kernel timestamp
(0.128 and 0.105): one assertion, twice, under two clocks. And

FAIL virtio_net_no_msix: "pcidev: PCI 00:03.0 NOT HANDED OVER — neither its MSI-X nor its MSI could be armed" never reached the boot console:
[kernel 0.339 cpu0] pcidev: PCI 00:03.0 NOT HANDED OVER — its MSI-X could not be armed, and a claim with no interrupt is a driver that would never be told anything
ALONE virtio_net_no_msix: red again, the same failure both times — the defect is real.

exit 1. That is the anchored match earning its place: the base refuses the
same function on the same slot, and the judge reds on the reason rather than
passing on the words NOT HANDED OVER appearing somewhere. Restore:
git reset --hard HEAD, git status --porcelain empty, git rev-parse HEAD
unchanged at d82dff33.

What the control does not discriminate, stated rather than implied.
pci_claim_caps_truncated cannot run on it at all, and no kernel is what
refuses it: the actuator and the staging it needs are part of the reverted
change, so the harness refuses the parameter before a guest is started —
tests/common/qemu.rs:2648, "pcidev-caps-truncated" is a kernel_params and the kernel declares no such actuator or parameter, exit 1 with nothing booted. Its negative control is mutation 1, which is the
same revert of the same decision with the instrument left in place.
https_tls13_e1000e stays green on the reverted base, exit 0: the e1000e
publishes MSI-X either way, so the base arms MSI-X too. That arm is a guard on
the owner's direction, shown by mutation 2, not a judge of this diff.
Refusal::MsixUnusable, Unarmed::Blocked, Armed::Msi and both disable_msi
sites likewise revert with every arm green, because nothing in any tier arms a
claimed function on MSI successfully. That is what
issues/kernel/nothing-reaches-the-msi-arm-of-a-claimed-function.md still
tracks, still a weakness, with the bench as its exit condition.

A mutation is a measurement only once the mutated tree is shown to build, so
each below quotes its build's exit status before its judge's — and mutation 5
is there because one spelling of it does not build at all. The build
is cargo build --target x86_64-unknown-none --features boot-actuators,test-actuators in kernel/, with target/debug on PATH for
toyos-ld — the same target and features src/clippy.rs's third shape and the
harness's own kernel build use.

Mutation 1 — the privilege decision, and it reds (re-run at this head).
bring_up's two NoTable arms replaced by one falling through to enable_msi,
with Refusal::CapsTruncated and its Display arm deleted — git grep -c CapsTruncated -- kernel matches no file — so the whole change is reverted,
which is also why it builds. Build exit 0, then
cargo test --test toyos-build -- pci_claim_caps_truncated exit 1:

FAIL pci_claim_caps_truncated: the claim this judges is the one on 00:03.0; this console refused []:
[kernel 0.338 cpu0] PCI 00:03.0: msi address=0xfee00098 data=0x00000000
[kernel 0.344 cpu0] pcidev: PCI 00:03.0 BAR 3 (0x4000 bytes) moved to 0xc0600000
[kernel 0.344 cpu0] pcidev: PCI 00:03.0 [8086:10d3] handed over on slot 0, vector 0x28
ALONE pci_claim_caps_truncated: red again, the same failure both times — the defect is real.
test result: FAILED. 0 passed, 1 failed, 0 stale or expired expected-failure entries, 0 invalidated, 1 total (6.5s)

The judge names what it judges and what the console did instead — refused []
is a boot in which no claim was refused at all — and the three lines above are
the hand-over that happened in its place.

BAR 3 is the BAR that function's MSI-X table register names (0xa4 = 0x00000003, BIR 3, offset 0, read off the device model), and the mutated kernel
moved it and handed it to netd with everything else. That is the escalation the
two arms stand between.

Mutation 2 — the ordering (at d82dff33). bring_up tries enable_msi
first and falls back to enable_msix, nothing else touched. Build exit 0,
then
cargo test --test toyos-build -- https_tls13_e1000e exit 1:

[kernel 0.673 cpu0] PCI 00:03.0: msi address=0xfee00098 data=0x00000000
FAIL https_tls13_e1000e: "PCI 00:03.0: msix address=" never reached the boot console:
ALONE https_tls13_e1000e: red again, the same failure both times — the defect is real.
test result: FAILED. 0 passed, 1 failed, 0 stale or expired expected-failure entries, 0 invalidated, 1 total (17.1s)

Every fetch, refusal and differential arm below it still passed — the card works
on MSI, which is why nothing but this assertion sees the order.

Mutation 3 — the arming's own answer (at d82dff33). enable_msix's
map_err(Unarmed::NoTable) replaced by one reporting every miss as Absent.
Build exit 0, then cargo test --test toyos-build -- pci_capability_walk
exit 1:

[kernel 0.075 cpu0] virtio: pci cap selftest FAILED on a list that cycles on itself: the arming reads absent, want truncated
[kernel 0.075 cpu0] virtio: pci cap selftest FAILED on a link that is not dword-aligned: the arming reads absent, want truncated
[kernel 0.076 cpu0] virtio: pci cap selftest FAILED on a link below the standard header: the arming reads absent, want truncated
[kernel 0.076 cpu0] virtio: pci cap selftest FAILED on a head the spec forbids: the arming reads absent, want truncated
[kernel 0.076 cpu0] virtio: pci cap selftest FAILED on a capability reached before a link the spec forbids: the arming reads absent, want truncated
[kernel 0.077 cpu0] virtio: pci cap split 8/13
[kernel 0.077 cpu0] virtio: pci cap selftest 15/15

with 15/15 green beside it: two counts, and only the one that read the
decision moves.

Mutation 4 — the judge's own address, and the partial fix it used to pass.
bring_up arms MSI first (mutation 2's defect) and the hand-over line prints
pci.dev + 1, so the kernel takes the older mechanism on the claimed function
and names a different one in the line the old judge read its address out of.
Against the judge as point 4 shipped it this was green: it found 00:04.0's
msix address= and called an MSI-armed 00:03.0 MSI-X-first. Build exit 0,
then cargo test --test toyos-build -- https_tls13_e1000e exit 1:

FAIL https_tls13_e1000e: this is an assertion about the claim on 00:03.0; 8086:10d3 was handed over on ["00:04.0"]:
[kernel 0.092 cpu0] PCI 00:01.0: msix address=0xfee00018 data=0x00000000
[kernel 0.243 cpu0] PCI 00:04.0: msix address=0xfee00078 data=0x00000000
[kernel 0.323 cpu0] PCI 00:03.0: msi address=0xfee00098 data=0x00000000
[kernel 0.331 cpu0] pcidev: PCI 00:04.0 [8086:10d3] handed over on slot 0, vector 0x28
ALONE https_tls13_e1000e: red again, the same failure both times — the defect is real.
test result: FAILED. 0 passed, 1 failed, 0 stale or expired expected-failure entries, 0 invalidated, 1 total (10.8s)

The capture is the whole argument: three msix address= lines are on that
console and one of them belongs to the claim. A judge that takes its address
from the guest picks whichever the guest offers it; this one names 00:03.0
before reading anything, and the msi address= on that slot is what it would
have gone on to refuse.

Mutation 5 — the recorded compromise, and it stays green (point 16).
place_bars's Some(index) == table_bar mutated to
(Some(index) == table_bar && false): build exit 0, then https_tls13 and
https_tls13_e1000e exit 0, pci_function_is_exclusive exit 0,
userdev_dma_fault exit 0. The bare false the tracker used to spell it
with does not compile — error: unused variable: table_bar,
-D unused-variables implied by -D warnings, build exit 101 — which is why
the issue file now carries the form that builds. This is the one mutation here
run to show that nothing reds.

Independent oracles, two, neither of them another agent.

1. Linux's own reading of the same function. /proc/interrupts on the T14
   names its NIC's interrupt IR-PCI-MSI-0000:00:1f.6 … enp0s31f6 and
   /sys/bus/pci/devices/0000:00:1f.6/msi_irqs/162 reads mode=msi. A driver
   nobody here wrote, on the same silicon, saying that function is an MSI part.
2. The PCI capability layout, as toyos-pci's tests encode it. PCI §6.7 fixes
   a capability pointer as dword-aligned and above the 64-byte standard header,
   which is what makes an early-ending walk a fact about the list and not
   about the function. An implementation that reads a misaligned pointer, a
   below-header pointer or a cycle as a clean end is red at
   a_pointer_that_is_not_dword_aligned_is_refused,
   a_pointer_below_the_standard_header_is_refused and
   a_pointer_to_a_visited_link_ends_the_walk; one that calls the terminator an
   early end is red at the_terminator_ends_the_walk and
   a_forward_chain_is_followed_to_its_end.

Green

Every row is the line the command printed in /Users/jan/Dev/jan/toyos-msi, with
the exit status of the command itself and never a pipeline's, measured at this
head.

command	printed	exit
cargo test --test toyos-build -- pci_claim_caps_truncated	PASS pci_claim_caps_truncated (2s) / test result: ok. 1 passed, 1 total (4.9s)	0
cargo test --test toyos-build -- pci_capability_walk	PASS pci_capability_walk (2s) / test result: ok. 1 passed, 1 total (3.3s)	0
cargo test --test toyos-build -- https_tls13 (the filter is a prefix, so it selects both bench names)	PASS https_tls13 (4s) / PASS https_tls13_e1000e (4s) / test result: ok. 2 passed, 2 total (6.0s)	0
cargo test --test toyos-build -- virtio_net_no_msix	PASS virtio_net_no_msix (2s) / test result: ok. 1 passed, 1 total (2.2s)	0
cargo test --test toyos-build -- pci_function_is_exclusive	PASS pci_function_is_exclusive (2s) / test result: ok. 1 passed, 1 total (3.4s)	0
cargo test --test toyos-build -- --nightly iommu_virtio_platform (the arm whose no-unit judge round 4 moved)	PASS iommu_virtio_platform (6s) / test result: ok. 1 passed, 1 total (7.6s)	0
cargo test --lib	test result: ok. 308 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out	0
cargo test --workspace --exclude toyos-build	139 test result: ok lines, 1367 passed, 0 failed, no FAILED line	0
the five cargo clippy shapes src/clippy.rs declares, run one by one as the host job runs them	no warnings	0 each
the negative control above (at d82dff33)	control kernel build 0; FAIL pci_capability_walk and FAIL virtio_net_no_msix	1 each, which is the result it is run for
mutations 1 and 4 (this head), 2 and 3 (d82dff33)	build 0 then judge 1, each above	1 each, which is the result they are run for
mutation 5 (this head)	build 0, then four names at 0 — that is the compromise point 16 records, not a guard	0, which is the finding

The price row is no longer a marker. pci_claim_caps_truncated entered
tests/test-durations as an UNMEASURED marker with shards=none, which is
the documented two-cycle cost of a new registration: the marker buys the name
one measured CI run and the next commit carries that price. Run 35100393637,
twelve hosted shards at a75b3828, priced it at 2583 ms, and its
test-durations-merged artifact carries the row; that run's durations job
reds by name on the committed marker — "committed UNMEASURED profile marker(s)
are provisional and may not land: pci_claim_caps_truncated" — and says to
replace it with the measured value. pci_claim_caps_truncated 2583 shards=12
is now the row. 2583 ms is under FAST_COMMIT_MS (8000), so Tier::Fast is the
tier its price gives it and no registration moves. That one row is taken and no
other: every other name in the merged artifact is this run's shard luck, which
src/durations.rs measures at 1.28x p10-p90.

Two reds in an earlier battery were a host going down. At 23ef7817
virtio_net_no_msix and pci_function_is_exclusive each failed with Boot timed out waiting for ===READY===; the console carried: nothing at all — no guest byte
at all, twice, in the minutes before the development host rebooted into a new OS
build and wiped /tmp. Both are exit 0 in the table above, which is measured
after that reboot, as is every other row in it.

Size

git diff --shortstat origin/main HEAD is 21 files changed, 712 insertions(+), 198 deletions(-); across kernel toyos-pci tests userland the --numstat sums
to +575 / −155. Nothing outside kernel/, toyos-pci/, tests/,
userland/netd/ and issues/ is touched by this branch's own commits: no Cargo
manifest, no NOTICE, no sourcegate row, no src/tiers.rs relegation row, no
CLAUDE.md, and no syscall added, changed or retired. What it does add to the
harness is one registered name, one actuators! row and that name's measured
price row.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK