[YUZHEthefool]

Plan item: STRICT-Q

Problem and outcome

STRICT-Q (#64) needs a strict pass at SMP-4. On that harness, seven network runtime cases defer only because the guest has no eth0: smp_test_4core.sh, smp_test.sh and extended_smp_test.sh boot without a network device. kernel_test.sh has had one since P1-A, and the same cases pass there.

This is batch S2 of the approved STRICT-Q design (Nilix-docs-private design/strict-q-deferral-inventory.md, decision D2(a), approved 2026-11-10). The three SMP harnesses now attach the same restricted user network as kernel_test.sh, so those cases run.

Related issue or audit finding

Related: #64. Design: Zero-kernel/Nilix-docs-private#4 (D2).

Design and scope

• Each SMP harness gains -netdev user,id=net0,restrict=on,ipv6=off -device virtio-net-pci,netdev=net0,romfile=, exactly as in kernel_test.sh.
  • restrict=on keeps the guest off the host network. SLIRP still answers the guest, which is all the network cases need, as they already show at runtime 1 and 4 vCPUs.
  • romfile= skips the iPXE option ROM.
• The seven cases are net_ns_tx_isolation, netns_config_isolation, netns_rx_ingress, netns_rx_pool_lifecycle, netns_rx_eth0_slirp, netns_arp_probe_tx and netns_pending_frame.
• gate_log_test.py gains a test that the three SMP harnesses and kernel_test.sh pass these arguments to QEMU, and that boot_check.sh does not.
• Not in this PR:
  • boot_check.sh. On 2026-11-11 the maintainer decided it gets no NIC for now; [RFC]: keep boot_check.sh without a NIC for now (STRICT-Q D2 residual) #103 records the decision and the options for later.
  • Any timeout change. The budgets were re-measured instead (see validation).

Kernel safety and invariants

• Trust boundaries and attacker-controlled inputs: the guest now has a restricted user-mode NIC on the SMP harnesses, as it already has on kernel_test.sh. restrict=on gives it no route to the host or the internet.
• unsafe / MMIO / page-table / usercopy justification: none; no kernel change.
• IRQ, preemption, lock ordering, and SMP behavior: the virtio-net driver and its IRQ now run under SMP-2/4/8/16/32 in these harnesses. They already ran at runtime 4 vCPUs.
• Fallible allocation, quotas, and rollback/commit ordering: unchanged.
• ABI/layout/syscall compatibility: none.
• Fail-closed and error-path behavior: unchanged. The gates still fail closed on any failed case or fatal marker.

Validation evidence

Public index: .validation/strict-q-s2/README.md. Receipts are archived privately in Zero-kernel/Nilix-docs-private#14.

Local (Fedora):

bash -n on the three harnesses / make lint / git diff --check      # all OK
python3 -m unittest scripts.tests.gate_log_test                     # 34 tests OK
python3 -m unittest discover -s scripts/tests -p "*_test.py"
  # 342 tests; the one error is iommu_device_probe_test's import path outside pytest (unrelated, as on main)

Negative control (local edit, never committed): restoring smp_test.sh from 2e09191 fails the new test in its smp_test.sh case.

Dev host, QEMU 8.2 (TCG), parent 2e09191 and this branch side by side, no retries:

Gate	Parent	This branch
strict SMP-4	FAIL, passed=38 deferred=36, 30.6 s	FAIL, passed=45 deferred=29, 30.1 s
strict boot / runtime / runtime-4	FAIL, 29/36, 36/29, 45/29	unchanged
SMP-2 (smp_test.sh)	QUALIFIED, 38/36, 27.9 s	QUALIFIED, 45/29, 27.3 s
runtime group	GATE-QUALIFIED ×3	GATE-QUALIFIED ×3
extended 8 vCPUs (completion mode)	QUALIFIED, 38/36, 36.1 s	QUALIFIED, 45/29, 37.7 s
extended 16 vCPUs	QUALIFIED, 38/36, 297.0 s	QUALIFIED, 45/29, 286.6 s
extended 32 vCPUs (one side at a time)	QUALIFIED, 38/36, 740.9 s	QUALIFIED, 45/29, 699.5 s

In strict SMP-4, exactly the seven network cases change, each from deferred to pass. No other case changes.

The extended runs come from a second batch. In the first batch, the extended harness was BLOCKED before QEMU started because my script left the host's zstd off PATH.

Extended CI on this branch, run 42978556364 (45924d6):

• Aggregate success, with every lane green.
• smp-8-16 and smp-32 are GATE-QUALIFIED on Ubuntu 22.04 and 24.04.
• The strict diagnostic lanes FAIL, as on main, with strict SMP-4 at 45/29 on both images (main: 38/36).
• In the retained counts.json, the seven cases pass at 8, 16 and 32 vCPUs on both images, with 45/29 at each size. On main's 24.04 smp-8-16 artifact they are deferred, at 38/36.

None of these is a strict pass.

Compatibility, performance, and rollout

The extended harnesses run in window mode: each guest runs for its whole window (900 s at 8 and 16 vCPUs, 3600 s at 32), and QUALIFIED means the suite completed inside it. Gate times against main's Extended run 42950345865 (297d7d5):

Gate	22.04 main → this branch	24.04 main → this branch
smp-8-16	1945.9 s → 1963.2 s	1926.4 s → 1961.9 s
smp-32	4030.6 s → 4025.9 s	4251.6 s → 4223.9 s
strict SMP-4	11.9 s → 11.7 s	13.6 s → 14.5 s

• Timeouts. No timeout changes.
• Margin at 32 vCPUs. CI does not record when the suite completed inside a window, so the CI margin under 3600 s is not measured. It did complete inside the window on both images.
• Dev-host completion times. In completion mode on the dev host, S2 is no slower than its parent at any size: 37.7/36.1 s at 8 vCPUs, 286.6/297.0 s at 16, and 699.5/740.9 s at 32, as well as at 2 and 4. The NIC's relative cost is therefore not measurable. The absolute CI margin is a separate quantity.
• Job time. The 22.04 smp-8-16 job took 46 minutes against 40 on main. The difference is its final-owner-16 gate (243.6 s → 539.5 s), which runs shared_final_owner.sh through kernel_test.sh. This PR touches neither; kernel_test.sh already had the NIC.

Backout is a revert.

Checklist

• The change is focused, bisectable, and free of unrelated refactoring.
• I added a regression test or explained why an automated test is not practical.
• I ran the relevant formatting, lint, build, runtime, ABI, SMP, storage, or fuzz gates listed above.
• New unsafe blocks have local SAFETY reasoning and a minimized unsafe scope. (none)
• I preserved IRQ/lock-order rules, bounded attacker-controlled work, and reserve-before-commit accounting.
• I updated architecture, safety, testing, roadmap, or user documentation when behavior changed.
• New fixtures/artifacts are minimal, reproducible, redistributable, and contain no confidential data.
• Breaking behavior, residual risk, deferred validation, and untested hardware are called out explicitly.