The owner's rulings of 2026-10-04 are recorded in their tracks, and the T14's root-bridge fixture becomes decoded values

[Japabu]

The owner's rulings of 2026-10-04 are recorded in the tracks they change, each quoted as the option text he chose and dated; everything around a quote is marked as the orchestrator's or the design's. One raw firmware fixture is replaced by its decoded values.

Net (git diff --shortstat origin/main...HEAD): 17 files, +251 −68. Production code: src/licence.rs −6 (one entry) and one doc line in toyos-acpi/src/resource.rs. Tests: toyos-acpi/tests +48 −41. Issues: +203 −9. Deleted: the 186-byte .bin and its SOURCE (−11).

1. "Local only; decode the 186 bytes": the T14's root-bridge list is decoded values

His option: "Full tables stay out of the repo (a copy you hold); the 186-byte fixture on main is replaced by decoded values, as 'Extracts only' says."

• toyos-acpi/fixtures/thinkpad-t14/root-bridge-0.bin and its SOURCE are deleted. So is its entry in src/licence.rs, the tree's file-to-terms table. NOTICE never named the file (grep -n "root-bridge\|thinkpad" NOTICE prints nothing).
• tests/common::t14_root_bridge builds the same list from its decoded fields:
  • I/O 0x3000..=0x3fff;
  • memory 0xa2000000..=0xbcffffff, granularity 0x20;
  • memory 0x4000000000..=0x603dbfffff, granularity 0x40;
  • bus 0..=0x79;
  • then the End Tag.
• The two tests that read the list run over the same 186 bytes they read before. Before the file was deleted, a test asserting t14_root_bridge() == include_bytes!(…root-bridge-0.bin) was applied as a checked patch, run green (cargo test -p toyos-acpi --test resource, EXIT=0, 12 passed), and reverted.
• The descriptor builder moved into tests/common, next to the table builders, and now takes every field. tests/resource.rs's well-formed qword calls it. Before this there was one builder; there is still one.
• The OVMF list is QEMU's firmware, so it is not covered by this ruling and stays as captured. It is one OVMF_ROOT_BRIDGE in tests/common, beside the T14's, read by corpus.rs and fixtures.rs.
• toyos-acpi/src/resource.rs's header line saying the corpus test runs over "both firmwares' committed bytes" is deleted: the T14's list is no longer committed as bytes.
• The ACPI track records the ruling next to "Extracts only".

Mutations. Each was applied as a checked patch, built (build EXIT=0 each), run, and reverted, and the tree was clean afterwards. The patches are posted as a comment on this pull request.

patch	test	exit
m1: the decoder's length truncated to 32 bits	fixtures::a_second_firmwares_bytes_decode_to_that_machines_own_windows	101 (refused as Inconsistent, expect panics)
m1	fixtures::the_windows_a_boot_printed_are_what_that_firmwares_own_bytes_say (OVMF)	0. Only the T14's numbers reach this defect, which is that test's stated purpose.
m3: the zero-length guard dropped	corpus::no_single_byte_mutation_of_a_firmwares_descriptor_list_panics_or_runs_away	101 (length - 1 overflows, resource.rs:189)
m4: the T14 list's bus descriptor dropped	the same sweep	101 (mutation count 83130 against 94860)

cargo test -p toyos-acpi at the fixture commit: EXIT=0.

2. The IOMMU threat model, "Refuse external, record reflash"

• Recorded in issues/kernel/the-iommu-refuses-nothing-yet.md.
• The reflash weakness is filed as issues/kernel/a-driver-that-reflashes-its-device-escapes-its-isolation.md:
  • kind: defect;
  • owner: the orchestrator, under the IOMMU track;
  • exit: a firmware-verification design, ruled by the owner and built, whose refusal and negative control are read by a test or a T14 row.
• That file describes how far a reflashed device reaches. This is marked as the IOMMU design's reading, not a measurement.
• The T14's external ports are 00:07.0 and 00:07.2 (Thunderbolt root ports, device ids 9a25 and 9a27), under units 1 and 2. Source: the iommu: lines of orch/536-metal-full.log. This is labelled the orchestrator's reading.

3, 9, 10. The IOMMU's default-deny root and hand-over: "Display and USB only", "Accept and file", "Allow it", "Apply it at hand-over", and the NVMe row

All five are recorded in the IOMMU track under one heading, which names its subject; the track defines no stages.

• What the gap is. The track describes the gap as it was put to him: VT-d Rev. 4.1 §6.6, TTM≠00 with CAP.ESRTPS clear. The "older protection registers" are PMEN (§11.4.8.1).
• The T14 does not have the gap. Every unit reports CAP bit 63 (ESRTPS) clear, and ECAP bit 52 (ADMS) and bit 43 (SMTS) clear. Unit 0's cap=0x01c0000c40660462 ecap=0x0000029a00f0505e; units 1–3 cap=0x00d2008c40660462 ecap=0x0000000000f050da. The same log names the one RMRR, 0x9c000000..0xa07fffff, scoped to 00:02.0 alone.
• The NVMe row. He answered "You can do with the t14 what you want" to the question whether a single read-only Identify may run on its own boot. The record quotes his words whole and says the grant goes beyond the question asked.
• "Accept and file" is filed now, as issues/kernel/a-unit-in-scalable-or-abort-mode-loses-translation-for-its-root-table-switch.md (kind: defect, owner the orchestrator under the IOMMU track). Its exit: on such a unit that reports CAP.PLMR and CAP.PHMR, PMEN's protected memory regions cover all of memory before translation goes off for the switch and are released only once it is back on; a host test reads that order, and is red with the PMEN step removed. It is a host test because no machine reaches the path: QEMU 11's vtd_cap_init always sets VTD_CAP_ESRTPS and defines PMEN_REG read-only zero, and the T14's units support neither mode. A unit reporting either bit clear has no fix under this exit: with either clear, that region's base and limit are read-only (§11.4.8.1), so PMEN cannot cover all of memory, and the same section plans the registers for deprecation. The file stays open for such a unit once the PMEN exit is met, with its own exit: no function behind it reaches memory while translation is off for the switch, read by a host test that is red with the fix removed. It names issues/kernel/a-unit-left-translating-passes-dma-untranslated-while-programmed.md as the defect that closes the gap where the switch may stay translating.
• The track has an owner and an exit. Owner: the orchestrator. Exit: a test or a T14 row reads each ruled refusal with its negative control. The refusals are:
  • the track's own isolation-scope rule, which the kernel does not build yet: a non-singleton scope refused by name for a function behind a PCIe switch, and admitted for a root-complex-integrated function;
  • a userland claim below an external port;
  • an RMRR'd function that is not a display or USB controller the RMRR names alone (where it is one, its region is mapped into its driver's domain);
  • both halves of "Apply it at hand-over": from the hand-over on, a device that is neither display nor USB faults on its own RMRR region, is logged and stopped, and the machine keeps running; a display or USB controller whose RMRR also names another device faults on that region the same way; a display or USB controller its RMRR names alone keeps that region. Each case has its own negative control;
  • the hand-over gap, logged on a unit that has it.

4. The kernel heap's goal, "Change the goal"

• issues/kernel/the-kernel-heap-has-none-of-slubs-hardening.md quotes the ruling and the goal as it was put to him. Its owner is now the allocator track.
• Its new exit is that the kernel heap is the allocator's kernel front, and host tests hold each part of the goal, each red against dlmalloc or against the front with that part removed:
  • no link or size stored inside an object;
  • a wild free and a double free each panic;
  • pointer-holding allocations and data-only allocations never share a page.
• The tests are marked as the orchestrator's reading of the goal, not his. The Linux evidence stays as the issue's record.

5. The allocator bar, "Yes, that bar"

• Quoted in issues/kernel/toyos-has-its-own-allocator.md.
• Its exit gains the bar in his terms: read by the portable Rust runner on ToyOS; within 10% of mimalloc for time and peak memory on the pinned set; faster than dlmalloc everywhere.
• The track now points at the heap defect, which its kernel front closes.

6. #629, "Design pass, then re-cut"

Recorded in issues/build/the-tooling-is-a-review-prompt-and-three-workflows.md, the track whose content-addressed-toolchain item #629 builds. #629 is not touched.

7. Trace order, "Both in parallel"

• Recorded in the latency track and the diary track (issues/diagnostics/nothing-in-the-machine-can-read-the-trace-ring.md).
• His text's "latency step 1 (interrupts on in system calls)" is step 2 in the latency track (issues/kernel/syscall-preemption-is-incidental.md), whose exit the mask_windows row reads. Both files state this mapping and label it the orchestrator's.

8, 11. The interpreter: "Like Windows, not Linux" and "Yes, one path"

• Both are recorded in the ACPI track.
• The _OSI option is quoted whole: "Yes to every published Windows version string, no to 'Linux' and 'FreeBSD', as Linux itself answers. The T14 then runs the path it was tested on: Modern Standby, CPU performance tables, 101-step backlight, thermal profiles, all devices present." No rationale of the orchestrator's is attached to it, since a track carries none.
• Where the power-off ruling lands. The track gains a named stage, "power-off through the server", labelled as the orchestrator's placement, blocked on the interpreter's evaluation of \_S5. Its exit: the kernel's \_S5_ reader, toyos-acpi/src/dsdt.rs, and its caller in kernel/src/arch/x86_64/power.rs are deleted, and a test that powers off through a broken server is red.

Gates

• cargo run -- --ci host at 27b7753e3: EXIT=0. During that run, the commit that came after it was being edited, and it changes only issue files.
• cargo run -- --ci host at the pushed head 77408f574: EXIT=0 (log orch/rulings2/ci-host2.log).
• cargo run -- --ci host at the pushed head 21ddf46c0: EXIT=0 (log orch/rulings2-r2/ci-host.log, Host: 73 step(s), all green).
• cargo run -- --ci host at the pushed head bad9f2f2d: EXIT=0 (log orch/rulings2-r3/ci-host.log, Host: 73 step(s), all green).
• cargo run -- --ci host at the pushed head 1d2eee6c3: EXIT=0 (log orch/rulings2-r4/ci-host.log, Host: 73 step(s), all green).
• cargo test -p toyos-acpi after the round-1 fixes: EXIT=0 (log orch/rulings2-r2/acpi-test.log).
• No guest test is reached: the change touches host tests in toyos-acpi, one doc line of its source and issue files, and no behaviour the image has.

Unsure

• Merge conflicts. Other branches edit the same files: the ACPI stage-1 build (ACPI track) and IOMMU stage 1: a claimed function speaks only through its own remapping entry, has no untranslated space, and no domain reaches a host bridge's window #710 (IOMMU issues, though not the track file). Whichever lands second merges.
• The two hand-over defects. IOMMU stage 1: a claimed function speaks only through its own remapping entry, has no untranslated space, and no domain reaches a host bridge's window #710 carries a-unit-left-translating-passes-dma-untranslated-while-programmed.md, which is already on main; the new scalable/abort-mode defect names it and covers only the units where §6.6 forbids the switch under translation. If IOMMU stage 1: a claimed function speaks only through its own remapping entry, has no untranslated space, and no domain reaches a host bridge's window #710 renames or closes it, that merge moves the citation.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8

[Japabu]

Mutation and equivalence patches for this pull request, each applied with git apply --check then git apply, built, run, and reversed with git apply -R (script orch/rulings2/mutate.sh).

equivalence.patch

--- a/toyos-acpi/tests/resource.rs
+++ b/toyos-acpi/tests/resource.rs
@@ -193,3 +193,8 @@
     bytes.truncate(40);
     assert_eq!(windows(&bytes, 8), Err(ResourceError::Unreadable { at: AT, len: 46 }));
 }
+
+#[test]
+fn decoded_t14_values_are_the_committed_bytes() {
+    assert_eq!(common::t14_root_bridge(), include_bytes!("../fixtures/thinkpad-t14/root-bridge-0.bin").to_vec());
+}

m1.patch

--- a/toyos-acpi/src/resource.rs
+++ b/toyos-acpi/src/resource.rs
@@ -170,7 +170,7 @@
         if kind == TYPE_MEMORY {
             let min = u64le(phys, head, QWORD_MINIMUM);
             let max = u64le(phys, head, QWORD_MAXIMUM);
-            let length = u64le(phys, head, QWORD_LENGTH);
+            let length = u64le(phys, head, QWORD_LENGTH) & 0xffff_ffff;
             let translation = u64le(phys, head, QWORD_TRANSLATION);
             let flags = phys.byte(head + GENERAL_FLAGS as u64);
             // A window of no length decodes nothing, and firmware emits one

m3.patch

--- a/toyos-acpi/src/resource.rs
+++ b/toyos-acpi/src/resource.rs
@@ -176,7 +176,7 @@
             let flags = phys.byte(head + GENERAL_FLAGS as u64);
             // A window of no length decodes nothing, and firmware emits one
             // where a range is declared and unused.
-            if length != 0 {
+            {
                 let refusal = if min.checked_add(length - 1) != Some(max) {
                     Some(ResourceError::Inconsistent { min, max, length })
                 } else if translation != 0 {

m4.patch

--- a/toyos-acpi/tests/common/mod.rs
+++ b/toyos-acpi/tests/common/mod.rs
@@ -148,6 +148,5 @@
         qword_descriptor(IO, 0, 0x3000, 0x3fff, 0, 0x1000),
         qword_descriptor(MEMORY, 0x20, 0xa200_0000, 0xbcff_ffff, 0, 0x1b00_0000),
         qword_descriptor(MEMORY, 0x40, 0x40_0000_0000, 0x60_3dbf_ffff, 0, 0x20_3dc0_0000),
-        qword_descriptor(BUS, 0, 0, 0x79, 0, 0x7a),
     ])
 }

[Japabu]

Review round 1, head 77408f574.

Net: 15 files, +186 −65. Production: src/licence.rs −6. Tests: toyos-acpi/tests +44 −39. Issues: +142 −9. Fixture .bin and SOURCE deleted.

Measurements read: orch/rulings2/ci-host2.log (head 77408f574, Host: 73 step(s), all green, EXIT=0); equivalence.log (decoded_t14_values_are_the_committed_bytes ok, EXIT=0); mutate.log (m1 T14 decode 101 while OVMF stays 0, m3 sweep 101, m4 sweep 101, tree clean afterwards). The fixture's tests still fail on what the bytes caught: m1's 64-bit length truncation is reached only by the T14's 0x20_3dc0_0000 window, and the equivalence run puts the sweep over the same 186 bytes. Nothing that identifies a machine entered the tree: the added material is PCI addresses, an RMRR range, Intel device ids and VT-d capability bits, all of which are model-level.

BLOCKER

• issues/kernel/toyos-runs-the-machine-in-acpi-mode-and-interprets-its-aml.md:63-66 — the "Like Windows, not Linux" quote stops at "tested on..." and is marked "cut there". The orchestrator holds his full option text: "Yes to every published Windows version string, no to 'Linux' and 'FreeBSD', as Linux itself answers. The T14 then runs the path it was tested on: Modern Standby, CPU performance tables, 101-step backlight, thermal profiles, all devices present." — As it stands, the record states his ruling more narrowly than he gave it. It drops the five things he named as the path the T14 runs. Quote the text whole, delete the "as relayed to this record, cut there" parenthetical, and update the PR body's "The _OSI quote is incomplete" item to match.
• issues/kernel/toyos-runs-the-machine-in-acpi-mode-and-interprets-its-aml.md:71-72 — "It applies from the interpreter's power-off stage on (the orchestrator's placement)" — the track has no such stage, so the placement points at nothing. It also narrows "Power-off always goes through the ACPI server" to an undefined later point, with no exit that reads the deletion. Either drop the placement and let the ruling stand as given, or name the stage it lands in with an exit something can read: the kernel's \_S5_ path (toyos-acpi/src/dsdt.rs and its caller kernel/src/arch/x86_64/power.rs:74-95) gone, and power-off red in a test when the server is broken.

NOTE

• issues/kernel/the-iommu-refuses-nothing-yet.md:41 — "on stage 2": the track defines no stage 2 (that numbering is IOMMU stage 1: a claimed function speaks only through its own remapping entry, has no untranslated space, and no domain reaches a host bridge's window #710's design). The subject named after it is enough on its own; the stage label points at nothing in the tree.
• issues/kernel/the-iommu-refuses-nothing-yet.md:50-62 — "Accept and file" and "Display and USB only" now bind the track, but the track has no Owner line and no Exit. Nothing readable holds the ruled refusals: external-port claims refused, RMRR mapped only for display and USB, and the logged gap filed as a defect when the hand-over is built. The PR body says 2b's design files the gap issue; the track does not, so that obligation lives only in a PR body.
• issues/kernel/the-iommu-refuses-nothing-yet.md:67-68 — "The row is allowed, on its own boot." His answer, "You can do with the t14 what you want", is wider than the question. Say that the grant exceeds the question, or drop the restatement and let the quote stand.
• issues/kernel/a-driver-that-reflashes-its-device-escapes-its-isolation.md:19-20 — "(its roasts, 2026-10-03 and 2026-10-04)" cites roasts that no file or pull-request comment in reach carries. Name where they are (a PR comment id) or drop the parenthetical.
• toyos-acpi/src/resource.rs:13 — "both firmwares' committed bytes": the T14's list is no longer committed as bytes. Delete the line; do not correct it.
• toyos-acpi/tests/corpus.rs:569 and toyos-acpi/tests/fixtures.rs:166 — the OVMF list is include_bytes!'d into a separate OVMF_BRIDGE in each file. Now that the T14's list lives in tests/common, one ovmf_root_bridge beside it would serve both.

REMOVE

• issues/kernel/toyos-runs-the-machine-in-acpi-mode-and-interprets-its-aml.md:66-68 — "The answers are fixed before the first table loads, since an SSDT queries _OSI while it loads (the orchestrator's note)." This is the orchestrator's design rationale in a track, which issues/README.md says a track does not carry.

SEND BACK

[Japabu]

Review round 2, head 21ddf46c0.

Net: 17 files, +238 −68. Production: src/licence.rs −6, toyos-acpi/src/resource.rs −1. Tests: toyos-acpi/tests +48 −41. Issues: +190 −9. Fixture .bin and SOURCE deleted. The numstat matches the body's figures.

Measurements read:

• orch/rulings2-r2/ci-host.log: Host: 73 step(s), all green at 09:36, after 21ddf46c0 was committed at 09:17 with a clean worktree; ci-host.exit EXIT=0.
• orch/rulings2-r2/acpi-test.log: every toyos-acpi binary ok.
• orch/536-metal-full.log: unit1 scope 00:07.0, unit2 scope 00:07.2, and rmrr0 0x9c000000..0xa07fffff scoped to 00:02.0 alone, as the track says.
• The VT-d Rev. 4.1 text (orch/vtdctx/spec/vtd.txt): §6.6 forbids changing TTM under TES=1 with ESRTPS clear, and §11.4.8.1 is PMEN_REG.

Round 1

• BLOCKER _OSI quote cut — CLOSED. ACPI track:63-66 quotes the option text whole, character for character against the owner's text in the brief. The "cut there" parenthetical and the body's "incomplete" item are gone.
• BLOCKER power-off placement pointed at nothing — CLOSED. ACPI track:85-89 names the stage, with an exit a build can read: toyos-acpi/src/dsdt.rs and its caller in kernel/src/arch/x86_64/power.rs:74-104, both of which resolve, are deleted, and a broken-server test is red.
• NOTE "stage 2" label — CLOSED.
• NOTE track had no owner and no exit — CLOSED as asked. Two new BLOCKERs below are on the exit's content.
• NOTE NVMe grant restated narrower — CLOSED.
• NOTE uncited roasts — CLOSED.
• NOTE resource.rs:13 — CLOSED, deleted rather than corrected.
• NOTE two OVMF_BRIDGE copies — CLOSED, one OVMF_ROOT_BRIDGE in tests/common.
• REMOVE _OSI rationale — CLOSED.

BLOCKER

• issues/kernel/the-iommu-refuses-nothing-yet.md:81-82 — the exit reads "a device reaching reserved memory not its own faults". "Apply it at hand-over" rules something else: "only display and USB controllers keep access to their reserved region; any other device's access is refused". That refuses a non-display, non-USB device its own RMRR region from the hand-over on. Default-deny already faults access to another device's region, so this bullet reads nothing the ruling added. It also never reads that a display or USB controller keeps its region. The exit states the ruling more narrowly than he gave it, and the body's §3 repeats the narrowing. Fix: the bullet reads both halves. From the hand-over on, a device that is neither display nor USB faults on its own RMRR region, is logged and stopped, and the machine keeps running. A display or USB controller the RMRR names alone keeps its region. Each half has its negative control.
• issues/kernel/the-iommu-refuses-nothing-yet.md:73-83 against :9-15 — the track's first paragraph says "What remains is the refusal". It names the isolation-scope rule: refuse a non-singleton scope for a function behind a PCIe switch, never for a root-complex-integrated function. The kernel does not build that refusal (git grep -i 'scope\|switch' kernel/src/arch/x86_64/vtd finds none). The new exit lists only the 2026-10-04 refusals, so the track could close on it with its own headline refusal unbuilt. Fix: the exit also reads that refusal, refused by name for a function behind a switch and admitted for a root-complex-integrated one.

NOTE

• issues/kernel/a-unit-in-scalable-or-abort-mode-loses-translation-for-its-root-table-switch.md:28-31 — §11.4.8.1 says PMEN_REG "is always treated as RO for implementations not supporting protected memory regions (PLMR and PHMR fields reported as Clear)". It also says "New software development should not use Protected Memory Registers as they are planned for deprecation", pointing to abort-DMA mode instead. A scalable-mode unit is exactly the newer hardware that may report both clear. On such a unit this exit can never be met, and the file does not say so. The exit should be bounded to units that report CAP.PLMR/PHMR, and the unit without them recorded. Neither QEMU 11 (vtd_cap_init always sets VTD_CAP_ESRTPS; PMEN_REG is defined RO 0) nor the T14 reaches this, so "a test reads that order" can only be a host test; the file should say which.
• issues/kernel/toyos-runs-the-machine-in-acpi-mode-and-interprets-its-aml.md:85-86 — "The ACPI server evaluates \_S5" needs the AML interpreter. The track defines no interpreter stage, and this stage does not say what it is blocked on, which issues/README.md asks of a track. Name the blocker: the interpreter's evaluation of \_S5.

REMOVE

• issues/kernel/the-iommu-refuses-nothing-yet.md:55-56 — "The T14's units report ESRTPS, SMTS and ADMS clear, so it is not one of those machines." The new defect file now carries this, word for word in substance, and the pointer on line 57 reaches it.

SEND BACK

[Japabu]

Review round 3, head bad9f2f2d.

Net: 17 files, +251 −68. Production: src/licence.rs −6, toyos-acpi/src/resource.rs −1. Tests: toyos-acpi/tests +48 −41. Issues: +203 −9. Since round 2 (21ddf46c0..bad9f2f2d): three issue files, +22 −9, and no source, test or manifest changed.

Measurements read:

• orch/rulings2-r3/ci-host.log: the run starts at 07:48:23Z and bad9f2f2d was committed at 07:48:02Z. The worktree is clean at that head. The log ends Host: 73 step(s), all green, and ci-host.exit is EXIT=0. The FAILED lines in that log belong to the loom and model negative-control steps, which the step totals count green.
• VT-d Rev. 4.1 (orch/vtdctx/spec/vtd.txt):
  • CAP bit 5 is PLMR and bit 6 is PHMR, as the defect states.
  • §11.4.8.1 makes PMEN_REG read-only "for implementations not supporting protected memory regions (PLMR and PHMR fields reported as Clear)".
  • The PLM base and limit registers are read-only with PLMR clear, and the PHM ones with PHMR clear.

Round 2

• BLOCKER: the hand-over exit read only another device's region. CLOSED. the-iommu-refuses-nothing-yet.md:83-86 now reads both halves of "Apply it at hand-over", each with its own negative control: a device that is neither display nor USB faults on its own RMRR region, is logged and stopped, and the machine keeps running; and a display or USB controller keeps its region. The "names alone" qualifier on the second half is the owner's own word, from "Display and USB only" ("whose reserved region belongs to them alone"), not the orchestrator's. Body §3 matches.
• BLOCKER: the exit omitted the track's own isolation-scope refusal. CLOSED. :75-77 reads the scope refusal for a function behind a PCIe switch and the admission of a root-complex-integrated function, as :12-15 rules them.
• NOTE: PMEN exit unbounded. CLOSED as asked: the exit is bounded to units that report PLMR and PHMR, and the test is named as a host test. One new NOTE below is on the added paragraph.
• NOTE: the power-off stage's blocker. CLOSED (ACPI track:87).
• REMOVE: the T14 ESRTPS/SMTS/ADMS sentence. CLOSED, deleted.

NOTE

• issues/kernel/a-unit-in-scalable-or-abort-mode-loses-translation-for-its-root-table-switch.md:36-37 — "either bit clear … §11.4.8.1 treats PMEN_REG as read-only there" — false of the spec. §11.4.8.1 makes PMEN_REG read-only only when both PLMR and PHMR are clear. With one of them clear, only that region's base and limit registers are read-only. The paragraph's conclusion holds: such a unit cannot cover all of memory. Its reason does not, and body §3 repeats it. Keep the record true: "with either clear, that region's base and limit are read-only, so PMEN cannot cover all of memory".
• issues/kernel/a-unit-in-scalable-or-abort-mode-loses-translation-for-its-root-table-switch.md:39-40 — "keeps the gap, logged, until a fix that does not rest on PMEN is found" — this residual has no exit. Once the PMEN exit is met on a PLMR/PHMR unit, this defect can close while a unit without those bits still has the gap and nothing tracks it. Either state that the file stays open for such units, with a readable exit, or file that residual separately with its own owner and exit.
• issues/kernel/the-iommu-refuses-nothing-yet.md:83-86 — the two halves leave one case unread: a display or USB controller whose RMRR also names another device. The first half covers only devices that are neither display nor USB. The second half covers only a display or USB controller its RMRR names alone. Read together, "Display and USB only" and "Apply it at hand-over" refuse that device its region from the hand-over on, and the exit should read that too. Otherwise the track can close with that refusal unbuilt.

REMOVE

(none)

LAND AFTER NAMED CHANGES