Project Tracker

Project Tracker

Last reviewed: 2026-09-07.

The current QEMU closure revision passes hosted, AArch64/x86_64 smoke, libc, dual-architecture all-queue NVMe interrupt, SVE2 per-task context, x86 HMAT/ 1-GiB/TLB, xaibootFS-v5 migration/scale, TLS xapt, and external network gates. The final consolidated report deliberately retains physical_qualification=false.

A transmit that never completed used to wedge this stack about one boot in eighteen. It was caught with the device reporting DRIVER_OK, no DEVICE_NEEDS_RESET, and a buffer offered on each queue that it never consumed -- a device with nothing to react to rather than one that had failed, because the queue was notified once and then only polled. Every virtio wait now re-rings while waiting, in all four drivers; the block driver had the same defect and had lost a filesystem metadata write to it.

Both ARM virtual-platform profiles pass at 8a1a8a9, the same tree for both: macOS QEMU ARM64 across boot/CPU/network/SSH, USB keyboard console, SVE2 per-task context, storage recovery, operations and shutdown, and repeat boot, on AAVMF/EDK2 47765fe344818cbc464b1c14ae658fb4b854f5c2ceffa982411731eb4865594d; and macOS VMware Fusion ARM64 across its four-vCPU boot, storage, network and SSH lifecycle, on Fusion 26.0.0 with chainloader b7fb993edf80e301b148a2076f8a9919c3d31936d2273f592d19c06b5ec1d3a5. Between them they qualify the secondary-CPU bring-up, the subsystem serialisation and the virtio notification work on real firmware rather than on none.

With the Intel result below, all three profiles are current at the same tree -- which had not been true for 140 commits. The ARM pair had been quoted at a much older commit, and was only noticed as stale when the sentence that happened to be hedging it was rewritten: check-doc-freshness.py then refused the page and named the commit it could no longer vouch for.

Intel VPS QEMU x86_64 was re-collected at ee9c621edde5315e0da37fb3ae328baf717318ee, and that result is now behind the current tree -- the RISC-V work since then has changed shared code that x86-64 compiles, so it stands for that commit and must be re-run. It was collected on the designated host (deltasona, Linux x86_64) with OVMF/EDK2 624e06de18b4fa535e90db7160d00d3d07d206422b89999bf1e27d920264e4e0 and QEMU 10.0.11 under TCG. All eight profile gates pass: boot/network/SSH, USB keyboard console, CPU matrix, platform inventory, NUMA firmware, NVMe storage, operations/shutdown and repeat boot. It needs that host; no ARM result stands in for it.

Collecting it found nothing wrong with XAIOS and one thing wrong with a gate. q35-high-core-256-x2apic boots 256 vCPUs under TCG, which costs about 517 seconds on an eight-core host against a budget of 480 hardcoded into the scenario -- so the matrix killed a machine that was booting correctly and reported missing markers. Given the time it needs, the same configuration passes outright with all 256 processors online. The budgets are now scaled by XAIOS_QEMU_MATRIX_TIMEOUT_SCALE, which is what this run used; unset, nothing changes. Nothing the scenario asserts was relaxed.

This is the only human-maintained XAIOS project tracker. Roadmaps, milestones, phase plans, open decisions, and risks are consolidated here. The Wiki does not retain previous tracker, roadmap, milestone, or phase-plan pages.

This page tracks open work only. Completed rows are removed after their named evidence gates pass; implementation history remains available in Git and the linked test evidence.

Released builds

Builds are published on the releases page; each carries a note recording the hypervisors and firmware it was booted on and what was not tested. What changed between them is in CHANGELOG.md; this page does not repeat it.

Build	State	Note
b4	current	Cut from a green CI run. Adds first-boot setup, an account and machine name a person chooses, and the fixes below.
b3	superseded — do not use	A machine configured with SSH keys and no password account refused every key login, and it was cut while CI was red.
b2	superseded	First build to ship USB and network-boot kits.
b1	superseded	First released build.

No released build has been booted on physical hardware.

Status codes

Code	Meaning
TESTING	Implemented, but the current acceptance run or physical qualification is still underway.
IN PROGRESS	Active implementation is incomplete.
NOT STARTED	No qualifying implementation has begun. An interface or fixture alone does not count.
BLOCKED	Work cannot proceed until the stated external decision or dependency is resolved.
FAILED	The latest required acceptance gate failed; the failure evidence must be linked in the item.
CLOSED	Resolved, and kept on the list rather than deleted because the reasoning is worth keeping findable. Not active work.
DEFERRED	Postponed on purpose. Not blocked by anything external and not abandoned -- it is simply not being worked on now, and saying so is more honest than leaving it among the open items.
NEEDS HARDWARE	Implemented as far as it can be here, and the remaining evidence can only come from physical machines. Not on the active work list: no amount of effort in this environment moves it, and leaving it among the open items makes the list read as further behind than it is.

QEMU status proves correctness and ABI behavior only. Physical support and performance require immutable evidence under the benchmark contract.

Supported environments

XAIOS runs on three hypervisors. QEMU covers two architectures, so four targets exist, but the platform contract is per hypervisor.

Firmware differences below are the hypervisor's, not XAIOS's: the system behaves identically wherever a capability exists, and where one is absent it degrades the same way everywhere. See Platform neutrality, which the build enforces.

Function	QEMU ARM64	QEMU x86_64	VMware Fusion ARM64	Virtualization.framework
Boots to a login	yes	yes	yes	yes
Durable xaibootFS volume	yes	yes	yes	yes
IPv4 by DHCP	yes	yes	yes	yes
IPv6 by SLAAC	yes	yes	F-03 not qualified	yes, unique-local only (V-03)
IPv6 by DHCPv6	client present, gated	client present	client present	client present
SSH server	yes	yes	yes	yes
SSH client, SFTP	yes	yes	yes	yes
Reachable from the host	yes	yes	yes	vmnet helper only, one direction at a time
Boots at 1, 2 and 4 GiB	yes	yes	yes	yes
Multiple vCPUs	yes, 130 gated	yes, 128/256 scenarios	yes, 4/4	yes, 8/8
Message-signalled interrupts	distributor	yes	PCI	none; every queue polls (V-02)
Framebuffer console	no, serial	no, serial	yes	yes when a display device is attached (--gui), driven directly over virtio-GPU because firmware publishes none; serial otherwise
USB keyboard input	yes	yes	provisioned, not gated	console input over virtio
Entropy protocol	virtio-rng	virtio-rng	F-05 none exposed	yes
Storage transport	virtio-MMIO	virtio-PCI, NVMe	AHCI	virtio-PCI
Network transport	virtio-MMIO	virtio-PCI	E1000E qualified; VMXNET3 works (F-02)	virtio-PCI
Applications gated	yes, by name	yes, by name	yes, by name	yes, by name
Boots the unified image	yes, gated	yes, gated	yes, gated	yes, gated
Automated gate	full CI	full CI	make vmware-fusion-smoke	make vz-gate, make vz-stress-gate
Unified-image gate	make unified-image-gate covers all four from one file; CI runs the two QEMU rows and reports the hypervisors as skipped
Verified by	CI, every push	CI, every push	make local-gates, required by make release-check	make local-gates, required by make release-check
Evidence class	correctness only	correctness only	Fusion 26H1 lifecycle	development target, not evidence

Device inventory differs because the hypervisors differ; the kernel discovers what is present rather than assuming a platform, so those rows are not defects. The rows carrying an item identifier are.

Open bugs

Defects with no fix in place. Fixed defects leave this table when their gate passes; the reasoning stays in the commit that closed them.

ID	Defect	Affects	Status	Notes
B-23	A v6 volume sometimes does not come back from a power cut	all four	FIXED	Root cause found and fixed; the CI failure itself was never reproduced locally, so this rests on the mechanism matching the symptom rather than on watching the original failure stop. read_metadata probes the primary metadata copy, and when the primary is unusable it falls back to the mirror. The fallback began by calling set_active_v5() -- a leftover from when v5 was the only format that had a mirror. The mirror's sector is computed from the active layout: sector 12546 on v5, sector 2102786 on v6. So a v6 volume with a torn primary went looking for its mirror at the v5 offset, which on a v6 volume is an ordinary data block, and whatever happened to be written there is what got validated. That fires only when the primary is torn -- exactly the crash case -- and its outcome depends on the contents of an unrelated data block, which is why it was intermittent rather than constant. The fix searches the layouts it knows instead of assuming one, skipping any whose mirror would fall outside the device, and takes the first that probes clean. Proven by tests/storage/test_xaiboot_fs_v6.c, which tears eight sectors across a v6 primary and requires the mount to succeed from the mirror at sector 2102786 with contents intact. The negative control was run: with the fix reverted the case fails at the mount, as it must. Reproduction under QEMU was attempted and did not occur -- three runs on macOS, four on the Linux VPS, all four kill points crossing on both volumes every time -- so the deterministic hosted test is the stronger evidence here and is what the fix is defended by. The earlier reporting defect that hid this (the aggregate gate matching recovered point=... without the volume suffix, so a v5 pass satisfied the v6 check) is fixed separately and the markers now name the format. A failing gate also keeps the whole boot rather than its last four thousand characters, and CI uploads it. What it prints inline took two corrections to get right: the last forty filesystem lines are a booted machine deleting scratch files, and the first forty are a small early volume that mounts before the persistent one. It now prints the mount decisions by name -- five lines out of three and a half thousand -- because persistent mounted v5 nodes=256 against v6 nodes=1024 says which format came back, and no valid filesystem at sector=N; formatting distinguishes a volume that was reformatted from one that was refused. Checked against a real captured boot rather than assumed. Fixing it surfaced a second defect in the same file that no test had ever reached: see B-24.
B-24	Renaming a directory on a v6 volume wrote 191 KiB past the end of a static array	all four	FIXED	Found while fixing B-23, not reported by anything. rename_node stages new paths in g_path_transaction and walks g_active_max_nodes rows of it three times. v6 raised that count to 1024; the array was still declared [XBFS_V5_MAX_NODES][XBFS_PATH_MAX] -- 256 rows of 256 bytes, 64 KiB -- so rows 256 through 1023 were cleared and read back 191 KiB beyond it, into whatever .bss follows. It had never fired because every rename test in the suite ran on a v5 volume, where the walk stops at 256. This is the same mistake write_limit() exists to prevent for g_file_buffer, made a second time in the same file. It is fixed by sizing rather than clamping: a rename that skipped the nodes past the limit would leave them holding paths under a directory that no longer exists, which is worse than refusing. A compile-time assertion now requires the array to cover every format's node count, and the boot-time self-test asserts the same thing at runtime, so raising a future maximum alone cannot reintroduce it. The test that reaches it renames a directory holding 401 nodes on a v6 volume, both ways, and requires every file back afterwards. The negative control was run: with the array back at its v5 size the hosted suite dies with a bus error. Because two instances of one mistake is a pattern rather than a coincidence, every static in the file sized by a version constant was then checked. There are three. g_metadata_buffer and the node table were already sized for v6 and have never been wrong; g_file_buffer is deliberately smaller and is bounded by write_limit(), which is the right trade because a v6 file may be as large as the volume. The two that were correct are now asserted anyway, along with g_active_path_max against its buffer, since nothing else would catch a third instance.
B-01	Outbound ProxyJump failed host key verification	x86_64 builds	FIXED	No longer reproduces, and I cannot say what fixed it. The full FreeBSD bidirectional suite now passes on emulated x86_64 -- 19 of 19 checks, including xaios_outbound_proxyjump_to_xaios and the invalid-spec rejection -- against a FreeBSD 15.1 amd64 guest under qemu-system-x86. The entry said reproduction needed a physical x86_64 host; that was wrong, since it failed under emulation, which is what has now been run. Something between the original sighting and now addressed it, plausibly the resolver work, and attributing it to a specific change without evidence would be a guess. Left as TESTING rather than closed: an intermittent failure that stops appearing is not the same as one that has been understood. The standing warning still holds -- do not "fix" host key verification by skipping malformed known_hosts lines, which falls through to the append path and downgrades verification for a host that already had a key. 2026-09-06 -- found by reading, and it was never about ProxyJump. The outbound SSH client read /home/admin/.ssh/known_hosts with one call into a four-kilobyte buffer and scanned whatever came back. Two consequences follow, and both present exactly as this row describes. A host whose entry lies past the buffer looks precisely like a host with no entry, so the client appends its key as new -- which for a host that already had a different key stored is host key verification switched off, silently, in the direction that matters. And where the cut lands inside a stored line, the half that survives fails to parse and the connection is refused for a mismatch that had not happened. Neither depends on the host or the network; both depend on how long the file happens to be, which is why it came and went and why nothing could be pointed at as the fix. A short read -- which a filesystem may return at any size -- does the same thing. The standing warning on this row is now enforced rather than remembered. The scanner lives in userspace/sshd/ssh_known_hosts.c with the file access as a callback; it reads the whole file a chunk at a time, carries a line across a chunk boundary rather than judging the half that arrived, skips a line longer than any this program writes as text rather than truncating it into a record, and distinguishes "cannot read this file" from "this file does not mention the host". The caller refuses on the first instead of appending a key it has no reason to trust. The append offset also comes from a stat that succeeded, because writing at zero lands on top of the first entry. Tested hosted with the old reader beside it as the negative control, required to fail each case: an entry past four kilobytes, an entry cut in half at byte 4095 (refused as a mismatch), seven bytes returned per read, an over-long line, a last line with no newline, and a file that cannot be read. make hosted-test.
B-27	A full-screen program's terminal restore was truncated	FIXED	xtop sends \033[0m\033[?25h\033[?1049l\033[0m\033[?25h\r when it exits -- the restore twice, once inside the alternate screen and once after leaving it -- and the client received the first copy and then two bytes of the second, ending mid-escape at \033[?1049l\033[0m\033[. Not the transport: the length was written out beside the literal as 24 for a string of 29 bytes, so five bytes never left the program. Nothing noticed because the first copy is enough to make the terminal usable -- the cursor is shown before the alternate screen is left. Every escape length in the serve path now comes from sizeof of a named string, because a constant beside a literal drifts when the literal changes. Evidence: the docker network suite asserts the whole restore and passes.
B-26	qemu-docker-network-suite fails its native xtop check on every architecture	FIXED	The check drives xtop through a PTY over SSH and requires \x1b[42;30m and XAIOS xtop help in the stream. Both are missing, on AArch64 as well as RISC-V, so this is not an architecture question: it dates from the xtop refactor that moved drawing into the screen framework's cells, after which no run of this suite happened. \x1b[42;30m appears nowhere in the tree any more -- xtop's header is now \033[48;5;70;30m -- so at least that marker is stale. The help title is drawn only as wide as st->columns, which over a container's PTY may be zero, and that is the first thing to check. Everything before it in the suite passes on both machines, including the 23 utilities and the full SSH/SFTP/UDP client suite. To close: decide which of the two markers describes behaviour that should still exist, fix or restate it, and run the suite on both machines. 2026-09-06 -- closed, and it was three separate stale claims and one real defect. The colour marker \x1b[42;30m was the basic-colour form xtop stopped emitting when it moved into the screen framework, which sends 256-colour SGR from the cell it paints. The help title is on the screen but not in the stream as one run, because only changed cells are sent and the rule's corner and dashes match the frame underneath; it is asserted by three help body lines instead, which do arrive whole. The meter checks looked for htop-style bracket meters in aligned columns, which xtop has not drawn since it was redrawn after mactop; they are restated against the rendered screen, via a small terminal model added to qemu_gate_lib that replays a stream into a grid -- the right tool for any gate reading a full-screen program. The terminal-reset check was asserted on a later plain shell session that never sends a restore and has nothing to restore; it belongs to the program that took the terminal. The real defect: the interactive path accepted an invalid --sort key and opened the monitor sorted by something the person had not asked for, where the one-shot path had always refused it -- so xtop --sort invalid over SSH hung the client for three minutes instead of answering. It refuses now, before entering the alternate screen. Evidence: the suite passes end to end on aarch64 and on riscv64.
B-02	Thread join failed under load, twice	TESTING	A defect that produces exactly this signature is fixed; whether it produced these sightings is inference, not evidence, and is recorded as such. A process waiting in xaios_thread_join runs pending threads on its own CPU while it waits, so user_thread_worker can be entered from inside that process's syscall -- the CPU already has a current process bound and its address space active. The worker ended by clearing to the kernel unconditionally, which left the outer syscall with no current process and the kernel's address space: capability checks on it fail and user pointers resolve in the wrong space, so it returns a wrong answer rather than an error. It needs a thread still pending when join runs, which is what a loaded host produces -- both sightings were under load, one on QEMU and one during a VMware Fusion profile run -- and it lands on a later thread than the one that caused it, which is why it never pointed at itself. The worker now saves the CPU's current process, address space and thread slot and puts them back, so a nested run is invisible to what it interrupted. The second sighting's log named a thread whose result was the abandonment sentinel with join reporting success, which is the shape this produces. Not reproduced deliberately: eight loaded boots were attempted and two completed before the run was cut short, neither failing, so there is no before/after reproduction. join now reports threads: join lost its process context once per join if the invariant breaks again, so a recurrence names itself instead of being inferred a third time. 2026-09-05 -- reproduced, and a second cause found and fixed. make qemu-libc-gate --arch aarch64 fails intermittently on this host: 6 runs in 32 before, in two shapes. The one that names itself is threads: user join timeout id=7 owner=24 state=2 target=1 running=1 with user create id=7 target_cpu=1 and id=8 target_cpu=1 above it -- two user threads placed on the same worker CPU. A worker CPU runs one thread to completion, so the second does not run alongside the first, it waits behind it, and the wait is invisible to the caller. The kernel-side placement has refused to double-book a CPU since it was written (cpu_has_thread_locked); select_user_cpu never asked. Round robin does not avoid it: the ordinal is shared with every other placement and the current CPU is skipped, so consecutive creates land on the same CPU whenever it wraps past it. Placement now prefers an idle worker CPU and falls back to any eligible one rather than refusing. The second shape, worker exit magic present but exited=0 with exit_cpu never set, is consistent with teardown after such a timeout but was not traced separately. Evidence: 35 consecutive passes with the change against 6 failures in 32 without it, the last 15 of those a deliberate control with the new pass disabled. To close: a stretch of loaded runs on hardware; this is one emulated host.
B-07	Applications were never run on two of the four images	Fusion, Virtualization.framework	FIXED	Fixed. Only QEMU built with XAIOS_BOOT_TEST_APPS=1, so the syscall suite, the network and SMP tests, the agent protocol, the pipe-and-redirect surface and the shell's own command surface had never executed on Fusion or Virtualization.framework. Both gates checked kernel markers -- kernel started, volume mounted, DHCP lease, SSH listening -- and a guest can satisfy every one of those while the programs a person would actually type do not work. Both now build with the applications and assert eight application markers each. 2026-09-07 -- both acceptance runs made. Virtualization.framework: vz-gate passes at 1024, 2048 and 4096 MiB, and its sixteen checks include all eight applications -- shell command surface, syscall and filesystem suite, C toolchain and EL0 runtime, system information, network, multi-core, agent protocol dispatch, pipe and redirect surface. Fusion: make vmware-fusion-smoke passes with the same application markers in BOOT_MARKERS, run today at 2048 and 4096 MiB and on both the E1000E and VMXNET3 profiles. The programs a person would actually type now run on all four images, and are asserted on every boot rather than having been checked once.
B-08	An unclean-boot marker put the guest into rescue mode	all four	FIXED	Fixed in the gates; the behaviour itself is by design. The lifecycle record lives at /state/lifecycle/ on the durable volume, and rescue mode is latched by a marker file there. build/xaios-persistent.img is shared: every QEMU boot writes to it, and the hypervisor gates copied it in. Enough hard power-offs across any gate -- which is how gates end, and how a demo VM gets closed -- and the marker is set. The guest then still boots, mounts, takes a DHCP lease and runs sshd, and refuses ordinary commands with "rescue mode permits diagnostics and filesystem repair commands only". vz-gate now generates a fresh durable volume per run rather than inheriting whatever unrelated gates left behind, and both hypervisor gates treat rescue=1 as a fault rather than a state a passing boot may be in. Worth knowing for a demo: repeated force-quits do eventually reach this, and that is the system protecting itself, not a defect. 2026-09-07 -- verified in the gates rather than in this row. vz-gate carries rescue=1 as a fault pattern and unlinks vz-persistent.img before every run, so it cannot inherit a latched marker from an unrelated gate; vmware-fusion-smoke carries rescue=1 in FATAL_MARKERS. Both were read in the source and both gates pass -- vz-gate at three memory sizes and Fusion four times today -- so a guest that reached a login prompt and then refused ordinary commands would now fail a gate instead of passing one.
B-19	The relocated kernel was placed without its required alignment	all four	TESTING	Fixed, and it is the reason CI was red for twelve commits. The loader took whatever address firmware returned, which is page-aligned and nothing more, while the kernel's segments declare p_align 0x10000 and objects inside it need up to 16 KiB -- the SMMU stream table among them. Landing 4 KiB off makes the hardware reject the stream table entry and the guest panics in smmu_self_test. The same commit passed locally and failed in CI purely because firmware put the kernel at 0xbc050000 on one machine and 0xbc049000 on the other, so it looked environmental and was not. The loader now takes the strongest p_align across the loadable segments and rounds the base up to it. Found by symbolising CI's backtrace against the load base the panic screen prints, which is the diagnostic added for B-15.
B-25	After reverting a Fusion snapshot the guest boots clean and then refuses every command	VMware Fusion ARM64	FIXED	Session-context exhaustion in sshd, and it was never intermittent -- it was deterministic in the number of connections. The kernel keeps sixty-four remote-login session contexts, allocated on the first call that names a session id, because a context holds that session's working directory and it has to survive between commands. The session id is the connection's socket handle, and socket handles come from a counter that only goes up (g_socket_next_id in kernel/user/syscall.c) -- they are never reused -- so every connection is a new id and a new context. sshd freed the context only when a flag said one had been opened, and that flag was set in exactly one place: execute_admin_command, after a command had succeeded. Every other way of reaching the kernel with that id allocated a context and set nothing -- a command the kernel refused (an unknown command comes back XAIOS_ERR_INVALID, and the syscall wrapper turns every non-OK status into -1), and, more often, an interactive shell, whose prompt asks the kernel for the working directory before the user has typed anything. Those contexts were never freed: the connection went away and the context stayed, for the life of the machine. After sixty-four such connections the table was full and every later session was refused inside remote_login_execute_session -- before remote_login_execute, which is the function that logs. That is the whole of the recorded evidence, in one mechanism: the guest boots perfectly (nothing is wrong with it until the sixty-fifth connection); SFTP keeps working (it does not take this path); every command answers Command execution failed (ssh_channel.c emits that when the syscall fails with no output); and no remote-login: line appears (the refusal happens before the logging function). The tracker's 'not session exhaustion' evidence -- forty consecutive sessions after a plain reboot -- tested forty successful sessions, which are the one case that set the flag and cleaned up, so it did not test this path at all. Fixed in three places. ssh_channel_close_connection now closes the kernel session unconditionally, by socket handle, for every connection it tears down; the flag is deleted rather than corrected, because it was one caller's record of a table it did not own and the next caller added would have got it wrong the same way. The close syscall no longer counts 'nothing to close' as a denial -- a malformed request is still refused, but the ordinary case completes, or every connection that never ran a command would put a rejection in the log and in the control-plane denial count. And the kernel's table now evicts its least recently used entry instead of refusing, so a future leak costs a shell its working directory rather than bricking the machine, and says so in the console -- the original defect's whole difficulty was its silence. Gated, with two negative controls. make qemu-ssh-session-exhaustion-gate (and the -x86_64 and riscv64 variants) opens eighty connections whose command the kernel refuses and then asks the guest to do something ordinary. It passes on all three architectures -- 89 distinct sessions, table never filled. On the pre-fix sshd with the new kernel it fails: the table filled 18 times in 80 connections. On the pre-fix sshd with the pre-fix kernel it reproduces the report verbatim -- after 80 connections the guest could not answer pwd: rc=1 stdout='Command execution failed\n', with ls / refused the same way. The gate asserts the table never fills rather than only that commands still work, because the new eviction backstop would otherwise hide a regression of the sshd fix; and it counts distinct accepted socket handles, because a stack that recycled them would make eighty connections one session repeated.
B-15	An intermittent fatal assertion on VMware Fusion	VMware Fusion ARM64	CLOSED	Closed on the evidence, and kept on the list because the reasoning is worth finding again. Still one occurrence and still no idea which assertion, but the evidence position has changed and one theory has been ruled out. 217 boots without it: the original 17, plus 200 consecutive on make vmware-fusion-boot-soak, every one reaching SSH, shutting down cleanly, and reporting unclean=0 rescue=0. That bounds how rare it is; it does not explain the one. The remedy this row claimed did not work. The panic screen was taught to print the load base and told the operator to subtract it and use llvm-symbolizer. Causing a panic and following that instruction shows both halves are wrong: subtracting alone gives an offset from the start of the image while kernel.elf links at 0x90000000, and the kernel carries no DWARF, so llvm-symbolizer answers ?? for any address. Had B-15 fired again it would have produced the same unreadable addresses as the first time. The working operation is runtime - load_base + link_base against the symbol table, and the panic now names tests/scripts/resolve-panic.py, which does it. The fifteen addresses are explained even if the fault is not. A deliberate assertion on Fusion produced sixteen frames of which two were real and fourteen were firmware memory -- a frame-pointer walk that leaves the kernel stack reports whatever words are lying there, formatted identically to real callers. The original record being fifteen addresses is what that looks like when nobody can tell which is which. Frames outside the kernel image are now dropped and the number dropped is printed. Proven on Fusion, not argued: make vmware-fusion-panic-capture builds a kernel that asserts on purpose, boots it, and requires the console to carry the cyan screen, the assertion, the load base, a backtrace, the replayed log and the halt line, then resolves a frame through the operator's own script and requires kmain. It does. Every claim in this row before today had only ever been exercised under QEMU. B-19 was the obvious candidate and is not the answer. It was filed the day after this one, is a panic whose occurrence depends on where firmware places the kernel, and this has not recurred since it was fixed -- a tidy story. Tested rather than told: with the alignment fix deliberately defeated and the kernel placed 4 KiB off, Fusion booted three times out of three to SSH ready. It is not susceptible to that class, which fits B-19's symptom being an SMMU stream table Fusion has no equivalent of. Also fixed on the way, all three of which would have wasted the next investigation: the smoke gate cleared its serial log after the image build, so a build failure printed the previous run's healthy boot underneath it; vmware-fusion-panic-capture passed its build flag to a script that only packages artifacts and builds nothing; and the kernel now prints its load base on every boot, so any console kept from a boot that later dies carries what its trace needs. Closed on the second of those two conditions: 217 boots without a recurrence, no cause ever identified, and a diagnostic path proven on the machine itself -- so a recurrence is answerable in one step rather than needing this row held open to catch it. Reopen on any further occurrence.
B-14	The x86_64 guest wrote to the medium it booted from	QEMU x86_64	TESTING	Partly fixed, and the remaining half is untestable here. Two separate things were wrong. The runner attached the boot drive writable where the AArch64 runner has always attached it read-only, so booting an image modified it -- that is fixed, and verified by checksumming the image either side of a run with no rebuild in between. The self-test also asserted that a write to the boot device succeeds, which would panic a machine booting a CD or a write-protected stick; it now asks whether the device advertises VIRTIO_BLK_F_RO and verifies the refusal instead, running everything that does not depend on having written. That path is unexercised: with readonly=on QEMU discards writes but still advertises the device as writable, so the guest reports medium=writable and takes the writable branch. Proving the read-only branch needs a device that actually advertises the bit.
B-12	Fusion faulted on the firmware framebuffer at 4 GiB	VMware Fusion ARM64	FIXED	Fixed. The guest took a level-1 translation fault on far=0xff0000000 in term_putc -- the framebuffer. Firmware places it above RAM, so with four gibibytes it lands at 63.75 GiB, well outside what the kernel identity-maps; with one or two it fell inside and worked. Nothing about the framebuffer changed between those cases, only how much memory sat underneath it. Writing to it worked before translation was enabled because firmware's tables covered it, and the kernel's tables map RAM plus the device windows whose addresses it knows -- a firmware framebuffer outside RAM is neither. kmain now maps it from boot->framebuffer_base immediately after vmm_init, before the next line is drawn. 2026-09-07 -- run at the size the row is about, which had never been possible. memsize was hard-coded at 2048 in the VMX template with no way to change it, so every Fusion gate ran at a size where the framebuffer falls inside the identity map and the defect cannot occur -- the guard was being exercised at the one value that cannot test it. XAIOS_FUSION_MEMSIZE exists now, defaulting to the qualified 2048. And nothing in the log said where the framebuffer was, so a 4 GiB boot and a 2 GiB boot both printed a working framebuffer and only one of them had exercised the mapping. The kernel reports it now, and the two boots are no longer indistinguishable: at 4096 MiB boot-ui: framebuffer mapped base=0xff0000000 bytes=0xc00000 ram_pages=1015659 -- 63.75 GiB, exactly the address this row names, against 3967 MiB of RAM, so far above memory and outside the identity map; at 2048 MiB the same guest reports base=0x70000000, 1.75 GiB, below RAM and inside it. make vmware-fusion-smoke passes at both, with the full guest closure. The 2 GiB boot is the control: it shows the two configurations genuinely differ, so the 4 GiB pass is this mapping doing work rather than the defect being unreachable.
B-11	Userspace and the identity map were the same addresses	all four	FIXED	Fixed. Userspace began at 4 GiB. The kernel identity-maps physical memory in 1 GiB blocks and the per-CPU roots copy that map, then replace the entry covering the user window with the user directory -- so a machine with 4 GiB of RAM gave the kernel's own 4-5 GiB of physical memory to userspace and lost it. VMware Fusion took a level-1 translation fault on the first access; QEMU ARM64 booted and failed self-tests further in; x86_64 was unaffected only because its identity map stops at 4 GiB, immediately below the window. Which machines noticed depended entirely on how much RAM they had, which is why two years of 2 GiB gates never saw it. Userspace now occupies the last gibibyte the kernel can address and vmm_init caps the identity map at XAIOS_USER_BASE, so the two cannot grow into each other whatever the machine has. x86_64 carried the old index as a literal 4 in three places -- corrected to derive from the constant, which is what made the first attempt fault on its first userspace instruction fetch. QEMU ARM64 now passes at both 2 GiB and 4 GiB with one image. 2026-09-07 -- the acceptance run exists now, and it is a matrix. make qemu-memory-matrix boots aarch64, x86_64 and riscv64 at 1024, 2048 and 4096 MiB -- nine boots -- and asserts more than that they booted: each one has to report managed memory matching what the machine was given, and the figures have to rise with the request. aarch64 979/2003/4051 MiB, x86_64 972/1996/4044, riscv64 1011/2035/4083; the shortfall is firmware-reserved regions. The rising requirement is the gate's control on itself: the three runners read three differently-named memory variables, so a gate setting the wrong one would boot three identical 2 GiB machines and pass every per-boot check -- three equal figures fail. Two flaws in the gate were found and fixed by running it: it booted through make qemu-<arch>, whose dependency is the release image, so it rebuilt release over boot-test and then read a suppressed kernel log as a broken address space; and its VMM markers were AArch64's wording, which silently never matched on the other two. It builds boot-test images itself and keeps one marker set per architecture now. The window has since moved to 255 GiB so that RISC-V's Sv39 harts can address it, which does not change this row's arrangement -- userspace is still the last gibibyte the kernel can reach and the identity map is still capped at it. RISC-V turned out never to have had that cap at all, though AArch64 has had one since this row was written; it does now.
B-05	One fixed kernel link address blocked a 1 GiB profile	all four	FIXED	Fixed. The kernel is built position-independent on AArch64 and the UEFI loader places it where the machine actually has memory, applying the R_AARCH64_RELATIVE relocations it carries -- 384 of them, and nothing else, so no symbol table is needed. Firmware picks the address, bounded below 4 GiB because that is how far the kernel's early identity map reaches. x86_64 stays fixed-address: its code model emits R_X86_64_32, which cannot appear in a position-independent link, and it already boots at every size. The loader accepts both and applies no bias to a fixed-address kernel. 2026-09-07 -- 1 GiB is a tested profile now, not a claim. make qemu-memory-matrix boots all three architectures at 1024 MiB as one of its three sizes, and 1024 is in it precisely because this row is what excluded it. All three boot and manage the memory they are given.
B-06	Virtualization.framework booted to nothing below ~3.5 GiB	Virtualization.framework	FIXED	Fixed, and it was B-05 all along. The floor was never a property of the platform: the kernel was built to load at a fixed 0x90000000 and Virtualization.framework has no memory there until it has enough of it, so the loader failed before anything could print. Bisecting it produced a number (3584 MiB boots, 3328 does not) that matched no placement model, which should have been the clue that the question was wrong. With a relocatable kernel it boots at 1024, 2048 and 4096 MiB, and the guard run-vz.sh carried has been removed. 2026-09-07 -- and the gate now runs at those sizes rather than the row asserting them. vz-gate had --memory-mib 2048 written into it: the one value between the 1024 that used to fail and the 4096 that used to work, so the gate guarding this row could never have seen the defect. It reads XAIOS_VZ_MEMORY_MIB now, the same variable run-vz.sh already took. Run at all three: vz-gate: passed at 1024, 2048 and 4096 MiB, each with the full sixteen checks.
B-04	Fusion intermittently gets no DHCP offer	VMware Fusion ARM64	FIXED	Recurred after being called fixed. The first fix was real -- every boot of every guest had used one hard-coded transaction id, which a server may ignore as a repeat -- and it was not the whole cause. A later run failed the same way: three DISCOVERs, no offer, the boot continuing without an address. Three attempts is what every occurrence has looked like, and that number was not a coincidence: the budget was split evenly between waiting for an OFFER and waiting for an ACK, which with doubling retransmission is three attempts in the first phase. The failures are all in that phase, so it now gets everything except a fixed reserve for the REQUEST -- a server that answers at all answers that one at once, having already chosen the address; a server still starting up is the case needing patience. Total budget raised from 15 to 30 seconds, paid only where there is no server. 2026-09-06 -- given a measurement, which it did not have. Nothing was checking. wait_for_boot returns whatever address the guest ends up with, and a guest that fell back answers SSH on the fallback perfectly well -- so forty boots could all have "passed" with a machine that never reached the network, and the only record that would have said otherwise was a console nobody read. vmware-fusion-boot-soak now requires a lease on every boot (network: DHCP lease ip=) and records, per boot and in the summary, how many retries each needed and whether the failure was a missing offer or a missing acknowledgement. The retry count is the point rather than a detail: the fix widened the window for the offer phase, and what would say it is doing work is offers arriving after two or three attempts rather than not at all. A run where every boot leases first time says something different from one where half of them need three. Still TESTING until a long run has been made against it, because a defect that stops appearing is not the same as one that has been understood -- but it is now a defect a run can fail on rather than one a person has to notice. 2026-09-07 -- the long run was made, and it explains the defect rather than outliving it. 100 consecutive boots on the qualified E1000E profile, bridged: 100 booted, 0 failed, 100 took a real lease, none hit a missing offer or a missing acknowledgement. What makes this evidence rather than a green tick is the retry distribution, which is not what the reasoning above predicted: every single boot retried exactly once, and always in the offer phase -- network: DHCP retry request=1 attempt=1 status=-4, request type 1 being DISCOVER, in 100 boots out of 100. Nothing is intermittent about it. The first DISCOVER is given one second plus up to a quarter-second of jitter, and on this LAN the router has never once answered inside that window; the second attempt waits two seconds and always does. The same line appears on the VMXNET3 profile, so it is not a driver behaviour, and it appears in no QEMU boot at all -- QEMU's built-in server answers the first DISCOVER every time -- so it is a property of a real network, which is exactly the thing this bug only ever showed up against. That is why three attempts was the signature. Under the old even split the offer phase got about seven seconds, which with doubling retransmission is three attempts -- and every recorded occurrence was three DISCOVERs and no answer, i.e. the budget running out at the end of that window on a network that needs at least two attempts on a good day. The offer phase now gets 26 of the 30 seconds. The widened window is load-bearing on every Fusion boot, not a margin held in reserve for a rare one, and that is a stronger statement than a hundred quiet passes would have been. Boots took 14.4 to 17.3 seconds; every console is kept under build/vmware-fusion/boot-soak/. Reopen on any boot that reaches the fallback address.
B-03	vmnet-helper spins a core while idle	FIXED	The relay returned as soon as it saw no machine attached, without reading the packet that woke it, so vmnet's event never cleared and the callback fired again immediately. The helper held a core busy for as long as anything was on the network, with its counters frozen because nothing was ever read -- 88% of a core with no guest, which is what corrupted the C-03 measurement. It now reads first and drops the frame if there is nowhere to send it, which is what an unattached interface should do. Fixed and rebuilt; unverified, because the running helper is the old binary and restarting it needs root. 2026-09-06 -- verified on the fixed binary. The V-03 work rebuilt the helper, so the relay the operator started was the new one. Measured idle with no machine attached: 20 milliseconds of CPU over 60 seconds, against the core it used to hold busy. The row was open only because the running helper was the old binary and restarting it needs root; that restart happened for another reason and the measurement came with it.

What ships, and how far along it is

Three bootable deliveries, and the engineering each one waits on. Status is what has been demonstrated, not what has been designed: PARTIAL means some of it runs and the rest has not been tried, and is never a way of saying nearly done.

#	Deliverable	Status	Where it actually stands
D1	USB image, every architecture	NEEDS HARDWARE	Off the active work list: what remains is a physical test, not an implementation. The released image is a hybrid ISO 9660 and GPT disk carrying both an AArch64 and an x86-64 kernel, firmware picking its own; the GPT and its EFI System Partition are what a stick boots from, so dd should produce one. Every part of that is exercised here except the stick: the same image boots as a disk in four environments under make unified-image-gate, and the partition layout it relies on is the one the installed-disk gate boots twice a run. The -usb kit ships the image, a write-usb.sh that names the target device back and refuses to write until it is typed, and a README covering both modes -- running from the stick without touching the machine's disks, and installing onto one. Installing from that stick works at all only since the GPT reader stopped requiring a header to declare exactly 128 partition entries: xorriso writes 248, both are legal because the specification fixes only the array's minimum size, and until then a machine booted from the unified image could not name the EFI System Partition an install copies from. Three checks in the control client separately made storage install impossible to invoke; make qemu-setup-gate now installs onto a disk from the menu setup offers. To close: dd the image to a stick, boot an AArch64 and an x86-64 machine from it, and record the firmware and model of each.
D2	Network boot for blank machines	TESTING	A blank machine boots over the network and installs itself. make qemu-netboot-gate runs four stages: firmware asks DHCP for a boot filename, fetches it over TFTP and runs it, and XAIOS comes up -- BdsDxe: starting Boot0001 "UEFI PXEv4", the loader reporting its embedded kernel and initial filesystem, and 54 files mounted; a medium holding the loader and nothing else booting the same way; that machine installing onto a blank disk; and that disk booting alone to a login prompt with SSH listening. Only the last two are evidence of an install -- the rest is the installer describing its own work. scripts/build-netboot-image.sh appends the kernel, the initial filesystem, an entropy seed and an unmodified copy of the loader to the loader as PE sections, which the loader finds by parsing the headers of the image firmware mapped for it. That is what network boot requires: firmware fetches one file and is done, so the file has to be the whole system; an ordinary loader on an EFI System Partition has no such sections and reads its files exactly as before. The loader copy is carried because a netbooted machine cannot write the binary it is running -- firmware maps a PE with its sections at their virtual addresses, so the image in memory is not the file it came from, and writing it back out faults the firmware before any XAIOS code runs. What it writes is an ordinary EFI System Partition: a machine installed over the network is not a special kind of machine afterwards. The fetch was once recorded as untestable because QEMU's EDK2 appeared to have no network boot drivers; that was wrong, and attaching the UEFI network option ROM QEMU ships gives firmware a stack that PXE boots. Doing it found a real defect -- the x86-64 kernel asserted at least two virtio devices exist, which every profile here provides and a PXE-booted machine with an e1000 does not. The -netboot kit ships both architectures' binaries, a serve-netboot.sh running dnsmasq in proxy-DHCP mode so it answers the boot question without competing with the network's own address server, and a README giving the option 93 architecture selectors. To close: the PXE stage runs on x86-64 only, because that is where a UEFI network stack is available as an option ROM -- AArch64 is covered by the medium stages, and firmware with NetworkPkg would close it. serve-netboot.sh is itself unrun: the gate's fetch is QEMU's built-in server, not dnsmasq. The shipped AArch64 binary is not the gated one, deliberately -- the gate's AArch64 stages need a boot-time install self-test no shipped image may carry -- so for a long time it had never been started at all. It has now: make boot-media-gate puts the shipped binary on an EFI System Partition and requires it to reach a login with SSH listening, which is everything after the fetch, since a netbooted machine runs the same image from memory that a medium hands it. What is still untested for that binary is firmware fetching it, not the binary. The check was confirmed able to fail by blanking a megabyte of its payload, which stops it reaching a login.
D3	Ready-to-run images per environment	TESTING	Five kits, built by scripts/build-vm-packages.sh and scripts/build-boot-media.sh: one per hypervisor, plus -usb and -netboot for the two routes onto hardware (D1 and D2). One image between the four that carry one, because the unified image already boots all four and copies would be chances to disagree rather than products; the netboot kit is the exception and is not the image at all, but a pair of binaries with the system inside them. Kits are release assets, not committed, for the reason the ISO is not. All four hypervisor kits were booted from their own archives: QEMU AArch64 and x86-64, Apple Virtualization.framework and VMware Fusion each reach a login prompt with a durable volume mounted, an address by DHCP and SSH listening. Building them found four flag omissions, each producing a machine that boots and then quietly does less than its README promises: virtio-mmio.force-legacy=false, without which QEMU presents a legacy device the driver will not take; the AArch64 NIC on the MMIO bus rather than PCI; disable-legacy=on on the x86-64 boot disk, without which that disk is not counted, every ordinal shifts and durable storage is sought past the last disk attached; and a writable volume on every profile, because the configuration sshd loads lives on durable storage. Each README records these, since anyone writing their own command line meets the same wall. make vm-package-gate boots all four from their own archives so a dropped flag fails something, make boot-media-gate checks the other two carry what their READMEs name, and make qemu-setup-gate sets up a machine that packages no account and then tests what that machine can do -- the name on its login prompt, the password opening a shell, a command in that shell being accepted, and the same menu installing onto a disk. A kit that cannot be attempted here is reported as not run rather than counted as a pass. To close: nothing in the packaging; D1 and D2 carry the remaining physical evidence.

Engineering these wait on

#	Work	Status	Where it actually stands
E1	Disk partitioning, formatting and install tooling	TESTING	Done to the point of working end to end: a running XAIOS partitions a blank disk, formats an EFI System Partition on it, copies its own loader, kernel, initial filesystem and entropy seed across, and the resulting disk boots on its own to a login prompt with SSH up and IPv4 and IPv6 configured. Nothing short of booting the result is evidence -- everything before it is the installer describing its own work. The pieces: kernel/fs/fat.c is an 8.3-only FAT16 writer (format, mkdir, whole-file read and write, streaming cross-volume copy) chosen over FAT32 because VMware Fusion silently boots nothing from FAT32; storage_admin gained the standard ESP type GUID, reachable as xaiosctl storage partition create ... esp; kernel/storage/install.c is the operation, which refuses to install onto the disk its source lives on. Three kernel defects were in the way, each correct for the test bench and wrong for a real machine: the PCI slot map reserved ordinal zero for firmware, excluding the only disk a one-disk machine has; the matcher took only modern virtio IDs, and QEMU presents transitional 0x1001 by default; and the MMU refused everything above 512 GiB, exactly where the 64-bit PCI window lives. TCR_EL1.T0SZ had been 16 all along, so only the level-1 table was missing, and a self-test now maps two pages up there. Three more were found by doing the install rather than by reasoning about it. Restricting the disk scan to "machines with exactly one disk" stopped an installed machine seeing its own disk the moment a spare was attached, which is the install case; worse, ordinal counting walks every MMIO device before any PCI one, so the PCI boot disk was unreachable at any ordinal once an MMIO device existed. allocate_cluster rescanned the FAT from the start on every call, which hung the machine silently for the twenty thousand clusters a 10 MB copy needs. And entropy.seed cannot be written as an 8.3 name, so the installed system had no secure entropy and refused to start sshd -- images now carry entropy.sed and the loader still accepts the old name. External evidence in both directions: mtools reads what XAIOS wrote, and XAIOS reads the ESP mtools wrote, with file sizes matching the build host exactly. The install is now reachable as xaiosctl storage install <disk> from <esp>, carrying the same bar as any operation that destroys a disk: an admin role on both connection and principal, a named actor, an operation id, the target disk's own GUID as confirmation, and an audit record naming the disk written. install_to_disk refuses outright to install onto the disk its source lives on, so a mistyped device name cannot overwrite the running system. Remaining: physical-hardware confirmation, which no gate here can give.
E2	Instruction-cost metric	TESTING	The baseline is recorded, committed and now checked against. Under -icount shift=0 the guest clock counts instructions rather than time, and make qemu-instruction-cost-gate compares three single-threaded figures against tests/fixtures/instruction-cost-baseline.json: a syscall at 494, a socket bind/close at 12149, a thread create/join at 23731. A later run reproduced two of them byte-for-byte and moved the third by -1.4% -- inside tolerance, and in the direction the word-at-a-time memcpy would push it. The four-thread figure is printed and never pinned: under -icount the virtual clock advances for every vCPU, so it describes how threads interleaved rather than what an operation costs, and two runs of an unchanged image gave 1842 and 1131. The per-boot deadline is 900 seconds, because a boot under -icount is far slower than a service boot and the gate's first deadline was the reason no baseline existed. Remaining before green: nothing reachable here. These are emulator instruction counts, which the evidence policy admits as correctness and regression evidence and not as performance claims; those need physical hardware under the benchmark contract.
E3	NUMA correctness	TESTING	Done this session. The self-test proved node-0 placement and never checked node 1, so an allocator ignoring its node argument would have passed; it now asserts placement inside node 1's range and that every CPU maps to exactly one node through both lookups. core_lease is not covered and cannot be: it leases a CPU you name, so there is no topology decision to test until node-aware selection exists.
E4	Multiqueue and RSS networking	IN PROGRESS	The first tranche is done and measured on a device that offers four pairs. The driver's per-queue state is a virtio_net_queue_pair_t rather than eighteen flat fields; every pair a device advertises is allocated, set up at its own queue indices (receive 2i, transmit 2i+1), has receive buffers posted, and is polled round-robin so a busy pair cannot starve the others; and VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET then tells the device how many are in service. That order is not cosmetic -- a device told to use four pairs delivers on four immediately, so sending the command before the buffers exist drops every frame landing on a queue nobody reads. On the Debian VPS, against -netdev tap,queues=4 -device virtio-net-pci,mq=on,vectors=9, the guest reports multiqueue=1 max_queue_pairs=4 and queue pairs serviced=4 offered=4, with distinct MSI-X vectors per queue, and boots through to SSH server: up and running (tcp/22) and a login prompt. XAIOS_QEMU_X86_TAP and XAIOS_QEMU_X86_TAP_QUEUES are what make that testable at all: SLIRP is single-queue, so on it a driver servicing four pairs is indistinguishable from one servicing one, and macOS has no tap device. Unset, every existing gate keeps the user network it had. Transmit now fans out too, by CPU rather than by cursor. The pair a frame leaves on is smp_cpu_id() % active_pairs, chosen before the lock is taken, because the point of a second transmit queue is not that frames alternate -- it is that two CPUs sending at once do not queue behind one lock. A shared round-robin cursor would reintroduce exactly the contention the queues exist to remove, in a line that looks like fairness. Receive keeps its cursor, where it is right: the device chooses which queue a frame lands on, so there is no affinity to follow. The completion token now carries the pair as well as the slot, since a waiter watching the wrong queue's used index waits for something that completed somewhere it never looks, and completions are drained across every pair rather than pair zero -- a pair nobody drains stops accepting work once its ring fills. Measured, including the unflattering part. On the VPS against a four-queue tap: queue pairs serviced=4 offered=4 and transmit pairs=4 frames_by_pair=4,0,0,0. Every frame went out on pair zero, which is the correct answer and not a broken one: a boot sends from a single CPU, so a per-CPU selector has one pair to choose. The distribution is printed whatever it says, rather than only when a second pair is used -- a line that appears only when it flatters is silent in the ordinary case and reads as an absent feature. What this does not yet show is two CPUs transmitting concurrently, which is the case the design exists for; nothing in a boot does that, and demonstrating it needs a multi-threaded sender rather than more driver work. RSS is done, and it needed the harness fixed before it could be seen. VIRTIO_NET_F_RSS is feature bit 60 -- the first feature this driver wanted above bit 31, so the high word stopped being a constant and became per-attempt. The device is asked for hashing and multiqueue together first, and falls back to the previous attempts when it has neither. Configuration is sent after the pair count, not before: the indirection table names queues, and naming one the device has not been told to service is a request it may refuse. On the VPS against a four-queue tap: rss configured hash_types=0x3f table=16 pairs=4 key_bytes=40 and queue pairs serviced=4 offered=4 rss=1, with the guest still booting to a login. All six four-tuple hash types; address-only hashing is deliberately not requested, since it puts every flow between the same two machines on one queue, which is the case multiqueue exists to spread. The key is fixed rather than random on purpose -- it spreads identically and keeps a capture reproducible, and it steers queues inside one machine rather than defending anything. The first run reported rss=0 and the driver was not at fault: QEMU defaults rss=off on virtio-net-pci, so the device never offered the feature. The harness now asks for rss=on,hash=on alongside mq=on -- without that it was testing half of what it appeared to. What remains: and this is TCG on one Linux host, so it is correctness evidence and carries no throughput claim under the benchmark contract.
E5	xaibootFS and xaiFS at scale	TESTING	xaibootFS records a file as extents rather than as a list of block numbers, which lifts both limits at once and makes a node smaller rather than larger. v6 volumes hold 1 GiB of data against v5's 4 MiB, 1024 nodes against 256, and a file may be as large as the volume rather than 256 KiB. With a bit per block instead of a byte the resident cost is about 850 KiB -- 256 times the capacity for less memory than the old node table alone. The hosted test writes a 1 MiB file, four times a whole v5 volume, writes 400 files, and requires all of it back after a remount. Which version a new volume gets follows the disk rather than a flag day: a device with room for v6 is formatted v6, a smaller one is formatted v5 exactly as before, and nothing is rewritten in place. Every existing volume in this tree is unchanged, which the same test asserts by formatting a small device and requiring it to come back v5. Doing it found two defects that predate it. migrate_volume_to_v5 exists to bring a v2, v3 or v4 volume forward and asked only whether the volume was already v5, so it treated v6 as old and rewrote its superblock as v5 -- silent data loss for any future version, not just this one. And the metadata mirror was probed only when the version was v5: writes alternate between two copies, so a v6 volume read the older one every time and came back exactly one write behind, with fsck reporting no errors because nothing was wrong with what it read. A v6 volume has now been through the power-loss gate. make qemu-storage-crash-test runs both metadata kill points against both volume sizes, and since the format follows the size, asking for both sizes is what exercises both formats -- each pass asserting the format it actually got, because a v6 pass that quietly formatted v5 would be a second v5 trial wearing a label. All four combinations lose power and recover locally, and recovery requires xaibootfs: persistent loaded so that a volume which came back by being silently reformatted does not count as having survived. In CI they did not always, and the reason is now known: see B-23. The mirror fallback assumed the v5 layout, so a v6 volume with a torn primary probed a data block instead of its mirror. That is fixed and covered by a deterministic hosted test with a negative control. Fixing it surfaced B-24, an overflow in the rename path that only a v6 volume could reach. Getting there needed the system volume rebuilt and re-armed for every pass rather than once per point: the kill fires while the pending slot is being committed, and the pass that crashes then recovers commits it, so the second pass found nothing pending and would have passed having tested nothing. Remaining before green: xaiFS is separately tested to 128 GiB sparse and is not part of this change.
E6	Cluster data plane	TESTING	A sealed frame now crosses a network between two nodes. make qemu-cluster-gate runs both ends: XAIOS seals a JOIN for a peer and sends it over TCP, a peer on the host opens it -- magic, version, epoch, sender and HMAC-SHA256 tag -- and seals a reply addressed back, which XAIOS opens and then refuses when the same frame arrives a second time. engine/src/cluster.c had framing, sealing, peer state and owner selection since it was written and never opened a socket, so every test of it handed a buffer between two functions in one process. It is now built for XAIOS itself and driven by /bin/clustertest; making it compile for a freestanding target meant it could no longer include <string.h>, so it declares the two functions it needs when __STDC_HOSTED__ is zero. The host peer is written against the format rather than against the implementation -- an independent reading of the layout in cluster.c -- so the two agreeing says the wire format is what that file documents, rather than one program reading its own output. /bin/clustertest says so and exits cleanly when no peer answers, because most boots are not part of a cluster and a node that refused to start without its peer would be worse than one that reports the absence. Both of those are now done. XAIOS is buildable as either end -- XAIOS_CLUSTER_ROLE_SERVER makes it listen rather than dial -- so the peer is a second XAIOS machine and not a program written from the header layout. make qemu-cluster-two-node-gate runs both ends here and requires the lines only a listening XAIOS produces: opened peer frame bytes=98 opcode=1 nonce=2 and sealed reply bytes=98 on one machine against round trip verified bytes=98 on the other, with the replay refused at both. And the topology has crossed a real network: the Intel VPS, brought current in one command because its clone was clean, ran the dialling machine while this laptop ran the listening one, over an SSH reverse tunnel rather than an exposed port -- the box's INPUT policy is ACCEPT, so a bound port would have been world-reachable, and the sealing key here is a fixture in the repository. Three things had to be built: a server reads the fixed header and takes the frame length out of it rather than guessing, the dialled address became a build-time figure so an image can be pointed somewhere real, and the runner can carry a host port to the guest's listener. Two mistakes are worth keeping: the accept loop treated an empty backlog as fatal when the syscall reports it as an error rather than blocking, so it announced no peer while the peer was still booting; and /bin is read from the initial filesystem volume rather than the boot image, so preserving only the boot image produced a server that dialled -- the gate now checks the built ELF carries the role it asked for. Remaining before green: nothing in the data plane. Membership, failure detection and owner selection across real nodes are the next layer and are not this row.
E7	Storage throughput, caching and power-loss evidence	TESTING	The block path moved 512 bytes per virtqueue round trip: buffer_size had always been a parameter of the virtio-blk submission helper and had always been validated and then ignored. Raising it to a mebibyte took a 64 MiB sequential write from 4177 to 1450199 kB/s and a read from 4104 to 2086401 -- 347x and 508x, with the baseline rebuilt from the same tree behind -DVIRTIO_BLK_MAX_TRANSFER=512 rather than remembered. A model read is bounded by hashing rather than by the disk, so two further things mattered: pread_verified read every byte twice, once to hash and again to fill the caller's buffer, and the hash ran in scalar C. It is one pass now, and the kernel installs the ARMv8 SHA2 compressor only after checking it reproduces the scalar one across 301 lengths -- a hash that is fast and wrong would corrupt every package it signs while passing all of its own checks. /models reads are cached in RAM a chunk at a time, the chunk being the unit of verification, so a hit skips the hash entirely: 153071 to 1761687 kB/s chunk-aligned and 38416 to 751289 for a 256 KiB window, at 71.4% and 95.9% hit rates. /bin was already RAM-resident and is now budgeted, reporting 7704 KB of a 64 MiB first step that grows to 128 and 256. Measuring it found more than it built. xaibootFS bounded writes against the volume format's limit while staging through a buffer sized for the previous one, so on any v6 volume a seek past 256 KiB and a write ran a memcpy off the end of a static array -- a kernel .bss overflow reachable from userspace through the ordinary file API. memcpy and memset were byte loops, which is every copy the kernel makes. Reads walked the entire chunk table to find the chunks a request touched, which is O(chunk_count) volume reads per read and ruinous at the 32000 chunks half a terabyte comes to. And a commit wrote its new catalog past the end of everything and moved the volume's tail over it, consuming 8192 bytes per commit that nothing ever reclaimed: 23799 commits to fill a 256 MB volume, and something like 131 GB stranded behind a 500 GB ingest. Two alternating catalog slots above a real data high-water mark fixed it -- 32 guest commits now move the tail by zero bytes. Power loss has evidence rather than an argument. make qemu-crash-safety-gate kills the emulator outright at random points during an ingest and then hashes every chunk the surviving catalog still calls complete; it tears both superblock slots directly, because a kill almost never lands inside one; and it flips a byte first to prove it can fail. make qemu-write-ordering-gate covers the half a kill cannot: the driver logs every write and flush, and the gate requires a flush between the catalog and the superblock that publishes it, which is what keeps a device with a volatile write cache from persisting the pointer before the thing it points at. Removing that flush makes it fail on all six publishes, which is how it was checked. The state such a device leaves behind is now tested rather than argued: make qemu-crash-safety-gate constructs a volume whose newest superblock is whole and whose catalog was never written, and requires that slot to fail its own hash and the volume to come back from the other one -- a commit lost, which is the trade, rather than a superblock followed to a catalog that is not there. Both slots are exercised and the check cannot pass vacuously, because it requires exactly the orphaned slot to be rejected. Remaining before green: no device here actually acknowledges a write and then loses it, so the state is constructed rather than provoked; an end-to-end demonstration still needs a block-device model that can drop unflushed writes on command. Absolute figures are QEMU/TCG and are comparisons between builds, not disk speeds.

Delivery order

Order	Workstream	Status	Current boundary / exit gate
1b	Physical Apple/ARM, Intel desktop, and Xeon qualification	NOT STARTED	Named hardware must pass firmware, device, durability, security, ISA-state, NUMA, soak, and benchmark contracts.
1c	Disk partitioning, formatting and install tooling	TESTING	A Unix-style tool set that partitions a disk, formats xaibootFS and xaiFS on it, and makes it bootable with XAIOS as the only operating system on the machine. The tooling exists and installs. This row said the opposite -- "there is no way to take a bare disk and produce a system that boots from it" -- while E1 above described the same work running end to end, so the two rows contradicted each other and a reader had no way to tell which was current. What is real: xaiosctl storage install <disk> from <esp> has a running XAIOS partition a blank disk, write an EFI System Partition, copy its own loader, kernel, initial filesystem and entropy seed across, and the resulting disk boots alone to a login with SSH up. What is not real is the exit gate. Both gates that demonstrate it -- make qemu-installed-disk-gate and make qemu-setup-gate -- run AArch64 QEMU and nothing else: three of the four environments are untested, and x86_64 has no install evidence at all despite running the same code. Exit gate unchanged: a blank disk partitioned, formatted and booted, on all four environments and on one physical machine. Implementation detail stays in E1; this row tracks the delivery only.
2	Qwen 3.8 support	NOT STARTED	Begins after physical platform qualification is accepted or explicitly deferred; official tokenizer, layer, logits, 32-step decode, session, and physical gates must pass.
3	Kimi K3 text support	NOT STARTED	Begins after Qwen unless reprioritized; KDA, Gated MLA, exact top-16 MoE, MXFP4, and token parity are mandatory.
4	Kimi K3 multimodal support	NOT STARTED	Separate vision preprocessing/tower/projection/position and golden image gates.
5	DeepSeek V4 Flash 0731 support	BLOCKED	The exact official release label and immutable source must be verified first.

Model support boundary

Model or format	Progress	Support boundary	Completion gate
Qwen 3.8	NOT STARTED	Roadmap target; no architecture adapter is claimed	Pin an immutable official configuration before tokenizer, tensor, layer, prefill-logit, decode, session, backend, and physical parity work.
Kimi K3 text	NOT STARTED	Interface only	KDA/MLA/MoE/MXFP4/operator and target-token parity on a real checkpoint.
Kimi K3 multimodal	NOT STARTED	Roadmap only	Separate official vision and multimodal golden acceptance.
DeepSeek V4 Flash 0731	BLOCKED	Roadmap only	Verify exact official source before architecture work.

Platform recommendations

Only open ARM/Intel/platform recommendations remain here. The complete numbered catalog stays in docs/PLATFORM-SUPPORT.json; no secondary page owns progress status.

#	Recommendation	Status	Evidence / remaining gate
P-05	Physical Apple NEON evidence	NOT STARTED	QEMU cannot satisfy this physical gate.
P-07	SVE/SVE2 backend	TESTING	ARM64 QEMU executes the SVE2 canary and preserves per-task Z/P/FFR state across scheduling and interrupts. A packed SVE inference kernel now exists and is verified against the scalar reference before it is used. xaios_packed_gemv_sve computes the quantized row product with runtime-length vectors and no scalar tail -- svwhilelt predicates the final partial vector, which is the case a hand-written remainder gets wrong by drifting from the loop above it. It is selected ahead of NEON, because SVE's width is the machine's rather than a fixed 128 bits. On QEMU with -cpu max,sve=on and 2048-bit vectors the guest reports packed=verified against scalar. Two things had to be true before it could run at all, and one of them was invisible. The platform declares whether SVE may be executed -- the kernel reads ID_AA64PFR0_EL1 and enables the extension first -- because a differential check cannot be the probe: an SVE instruction on a CPU without SVE traps, so the check would be the crash. And the packed engine was compiled for x86-64 only, so the AArch64 kernel had never linked a packed kernel of any kind; the NEON path in it had never run in a booted system on this architecture. A correction worth keeping. The first version guarded the SVE code on __ARM_FEATURE_SVE, which is defined only when the whole file is built with +sve -- which this kernel must not be, or the compiler may emit SVE instructions in code that runs without it. So the kernel was compiled out entirely and the guest reported declined by differential check: indistinguishable from a kernel that had been tested and rejected. Per-function target("+sve2") fixes it. The kernel also uses merging predication rather than the _x forms; that was not what the check rejected -- built with _x it passes here, because QEMU's inactive lanes come back usable -- which is the argument for merging rather than against it, since depending on architecturally undefined lanes is a latent bug and not a working kernel. Remaining: GEMM as well as GEMV, physical qualification, and performance evidence under the benchmark contract. Backend selection stays fail closed.
P-15	RISC-V (rv64gc) as a third architecture	TESTING	Functional parity on the QEMU virt board, in the release image, and gated three ways; what it lacks is hardware. Boots to 100% on four harts with a login prompt and sshd answering, from a kernel handed to QEMU and from its own disk through EDK2 via the verified signed A/B system slot; the unified release ISO now carries all three architectures and boots this one. Sv48 with per-section kernel permissions, ecall syscalls over a full trap frame with the user-access window closed except across dispatch, PLIC, PCI over ECAM, both virtio transports, xaiFS at /models, a Goldfish clock, IPv6, the hosted ISO C99 library, xapt, and secondary harts that sleep and are woken by SBI IPI. The neutrality rule kept pushing back in the other direction: this port found the panic backtrace walking a frame layout only two of three architectures use, klog with no %c, an ELF loader that rejected foreign binaries silently, the ECAM enumerator filed under arch/aarch64, a PCI probe that could not tell an absent bridge from a present one where an unbacked read faults, a panic screen that was cyan only over serial, a C99 probe that asserted a result a uniprocessor cannot produce, and its own boot stack sitting outside every program header so the allocator handed it out as free memory. Absent: hardware qualification of any kind -- one emulated board is the whole evidence -- interrupt-driven virtio, which needs the shared asynchronous queue self-test to stop assuming polled completion, and a test matrix three gates wide against roughly seventy. To close: a RISC-V machine. 2026-09-06 -- the shared gates, and what porting each one found. Nine gates that had never run on this architecture were taken on. Four are done and passing: qemu-cluster-gate and qemu-cluster-two-node-gate (a sealed frame crossing between two RISC-V machines, opened and answered by the far end), qemu-cpu-matrix (twelve harts) and qemu-matrix. Three are close, each having found a real defect on the way, and two -- the FreeBSD suites -- are ported and not yet run. The pattern held: every one of them found something missing on this side rather than broken in shared code, and two found defects in shared code that were nobody's architecture. The image carried no clustertest at all, and neither builder took XAIOS_CLUSTER_TEST, XAIOS_CLUSTER_ROLE_SERVER, XAIOS_INSTALL_SELF_TEST or XAIOS_SSH_CLIENT_IDENTITY_FILE -- the last meaning a guest that could be logged into and could log into nothing. The runner had no --dry-run, no XAIOS_RISCV64_CPU, no cluster host forward, and no override for the volume /bin is read from. XAIOS_SSH_USERS_FILE=none was read as the name of a file rather than as "package no account", which made the setup gate unrunnable here. Two shared defects this architecture exposed. kernel/storage/install.c chose the removable-media loader name as "AArch64, otherwise x86-64", so a RISC-V machine installing onto a disk wrote nothing to the path its firmware opens; it is named per architecture now, with an #error rather than a fallback. And kernel/fs/fat.c was 8.3 only -- \EFI\BOOT\BOOTRISCV64.EFI does not fit -- so this machine could format an EFI System Partition and not put its own loader on it, and could not see that file on a volume mtools had written. FAT now does long names, gated against mtools reading back what XAIOS wrote. Two facts about this machine a gate must not assume. Under EDK2, which hart the firmware keeps for its MP services is not deterministic: three consecutive boots of one disk kept hart 3, kept hart 2, and kept none -- so a gate asserts the relationship (online plus firmware-refused equals capacity) rather than a number. And the kernel needs Sv48: five of twelve QEMU harts offer only Sv39, including rva22s64 and rva23s64, the standard RISC-V application profiles. The kernel refuses those in one clear line rather than falling back, and the CPU matrix now requires that refusal -- which makes Sv39 support a known, scoped gap rather than an unknown one. Still open on this row, unchanged: hardware qualification. One emulated board remains the whole evidence. 2026-09-07 -- all nine are closed. qemu-cluster-gate, qemu-cluster-two-node-gate, qemu-cpu-matrix, qemu-matrix, qemu-installed-disk-gate, qemu-netboot-gate, qemu-setup-gate, qemu-freebsd-network-suite and qemu-freebsd-bidirectional-suite all pass on riscv64, and the architectures that already had them still pass. The last two are the substantive ones: FreeBSD 15.1's OpenSSH, SFTP and UDP against XAIOS on riscv64, and then the same in both directions -- nineteen checks including this machine dialling out over SSH and SCP, a ProxyJump through itself, agent forwarding, an encrypted ed25519 key, and a wrong password refused. Two more things were simply absent from this image, both found by a gate rather than by reading: /bin/clustertest, and /bin/ssh and /bin/scp. Without the second a RISC-V guest could be logged into and could log into nothing -- it answered outbound child launch failed: client app missing, which is a true statement about a missing file and reads like a broken network. And one kernel defect that had nothing to do with any of them. The setup gate's install left /bin/xaios-setup unable to print or exit, both syscalls refused for capabilities it held. The kernel's per-CPU current-process table had been overwritten: on this architecture the kernel carves its own 64 KiB boot stack in the linker script -- AArch64 is handed one by firmware -- and it grew down from __stack_bottom at 0x80c0d000 into the tail of .bss, which ended at 0x80c0cb60 with those statics at 0x80c0ca68. The deepest chain this kernel has is an installer walking a FAT directory from inside a syscall from inside osctl, and it went over. There is a guard page below the stack now, unmapped once paging is on, so the next overflow is a page fault at a named address rather than a corruption that surfaces somewhere unrelated; and 256 KiB above it. What is left on this row is what it always was: hardware qualification. One emulated board remains the whole evidence, and nothing done here changes that.
P-14	Physical Intel/Xeon evidence	NOT STARTED	Physical firmware, ISA, NUMA, storage, network, thermals, and sustained-load gates remain.

VMware Fusion ARM64 remaining work

The qualified Fusion boundary is Apple Silicon VMware Fusion 26H1 (26.0.0), four vCPUs, E1000E, AHCI, DHCP IPv4, and public-key SSH/SFTP. The items below are intentionally not implied by that passing profile.

ID	Item	Status	Evidence / remaining gate
F-01	Fusion multi-vCPU startup	TESTING	Fixed, and it was ours. Fusion runs four vCPUs: telemetry: boot_summary cpu_online=4, full smoke gate passing. Two earlier diagnoses were wrong and the way they were wrong is the useful part. The premise that Fusion would not start secondaries was wrong -- it starts all four. The second, that Fusion refuses atomics and the cause was below the guest, was wrong because it rested on the wrong measurement: the descriptor read back was for an unrelated .bss word, not the page that faults, and every green Fusion boot had run with one CPU online, where the spinlock takes a fast path that skips the atomic entirely -- so no passing boot had ever executed one. A probe that forced an atomic showed it working. The real defect: a secondary publishes online = 1 while its MMU is still off and only activates the kernel's tables after the rendezvous. In that window the boot CPU sees online > 1 and switches to real atomics, while other live CPUs view the same memory as Device rather than Normal cacheable. An exclusive on a location whose attributes differ between PEs is not architecturally supported, and a platform may refuse it -- Fusion does, with DFSC 0b110101. QEMU and Apple's hypervisor permit it, which is why nothing else ever showed it. Locks now switch to atomics at smp_release_secondary_schedulers, before any secondary enters kernel code, so every CPU agrees on the attributes by the time one is taken. numvcpus is 4.
F-02	VMXNET3 networking	FIXED	The qualified profile still uses PCI E1000E and is unchanged. A VMXNET3 driver now exists and the device activates; it cannot yet carry a frame. What is proven on Fusion 26.0.0: PCI discovery of 0x15AD:0x07B0, both BAR windows mapped, revision and UPT version agreed (revision=1 upt=1), link state read (link=1 speed=10000), and the permanent address read back as 00:0c:29:90:da:fd -- which is exactly the address Fusion generated for the machine, so the register offsets are confirmed rather than plausible. The device then accepts the driver-shared area and hands over its rings: vmxnet3: activated tx_ring=32 rx_ring=32 mtu=1500, and network-device: selected vmxnet3. What does not work is transmit completion. Every send times out waiting for a completion descriptor, so DHCP never gets a lease -- 284 timeouts in a boot, and the IPv4: line that follows is the stack's fallback rather than a lease. Receive is therefore also unexercised: nothing has been sent to draw a reply. Transmit is still broken, but it is now bounded rather than guessed at, and most of what was suspected has been ruled out by measurement. The device is healthy and busy: receive works on the same rings -- frames arrive unprompted from the NAT and the device's own receive counters agree with what the driver saw, which also serves as the control proving the transmit counters are read from the right offsets rather than being zeroed memory. Eliminated, each with evidence rather than argument: the doorbell window is live (IMR reads back what is written; BAR0 and BAR1 sit at distinct page-aligned addresses); DMA reads work (deliberately corrupting the shared-area magic gets activation refused, so the device really does read guest memory at the address given); the queue descriptor holds exactly what was intended, read back from the bytes the device parses (ring_pa matching the ring's own translation, tx=32 comp=32 threshold=1 numTx=1 qdesc_len=512); the descriptor is byte-identical to what the reference driver emits for a single-fragment 300-byte frame (word2=0x412c word3=0x3000 -- len 300, gen 1, EOP and CQ set); every offset, shift and sentinel was rechecked against VMware's published definitions rather than recalled, including the two that had been suspected (TXD_GEN_SHIFT 14, TCD_GEN_SHIFT 31, INIT_GEN 1, and both queue control blocks being sixteen bytes); and it is not slowness or a missed doorbell, since re-ringing every 100 ms for three seconds changes nothing. What the device says: queue not stopped, no error, no event, and zero packets transmitted, errored or discarded. It is not refusing the work; it never takes it. Corrected on the way: the first version of this diagnostic read queue status and statistics straight out of memory and reported all zeros, which VMware's definitions mark as "driver read after a GET command" -- those numbers were the calloc, not the device. GET_QUEUE_STATUS and GET_STATS are issued first now. Two genuine defects were fixed alongside: the second receive ring was never given a producer index, and the driver-data pointers were left at zero where the reference uses an all-ones "none" sentinel, zero being a physical address a device is entitled to read. The interrupt hypothesis is now eliminated too. Clearing intrCtrl so the device may deliver interrupts changes nothing: 284 timeouts, no packets counted, and the address that follows is still the fallback rather than a lease. So it is not that this Fusion build requires interrupt delivery before it will consume a transmit ring. Where to look next: what remains untested is the device's own internal transmit consumer index after activation, which no register exposes, and GET_CONF_INTR -- never asked what the device offers, though enabling delivery with the configuration it was given made no difference. Everything reachable from the driver side has now been checked; the next step is likely to be a packet capture on the host side of the Fusion switch, to see whether the device emits anything at all. Getting activation to succeed took four layout corrections, and it is worth recording that one of them was self-inflicted: mtu is a 32-bit field, the first version had the offsets right, and a later correction that assumed 16 bits moved the queue counts onto padding, so the device read a driver asking for no queues. The layout was settled by checking VMware's published definitions rather than by another round of recall. Nothing here is reachable by accident: VMXNET3 is selected only after E1000E and only if it activates, and XAIOS_FUSION_NIC defaults to e1000e, so the qualified profile cannot drift onto it. make vmware-fusion-smoke, make qemu-smoke, make qemu-x86_64-smoke and make docs-check all pass with the default. 2026-09-06 -- the host says what is wrong, and it is the receive path. The step this row has been waiting for was a host-side view, and it did not need a packet capture or root: VMware's own vmware.log carries, repeatedly and once per delivery attempt, VMXNET3 hosted: Cannot retrieve the buffer descriptors per rx packet. That is the device saying it cannot obtain receive buffers from the rings the driver gave it -- so nothing can be delivered to the guest, and the receive counters this row previously reported as working now read zero on Fusion 26.0.0 build 25388279. One real driver defect found and fixed by it: VMXNET3 receives into two rings, ring1 for a packet's head and ring2 for its body, and only ring1 was ever filled -- while the doorbell told the device thirty-one body descriptors were ready. The device was pointed at thirty-one descriptors of zeroes with the generation bit clear. Ring2 is filled now, with btype 1 and the driver's generation. It did not clear the message, and neither did raising maxNumRxSG from 1 to 2, which was tried and reverted as an unjustified guess. GET_CONF_INTR, asked for the first time, answers 0x0 -- type 0 (auto), 0 vectors -- and the device id reads 0x1:0x07b0. Transmit still times out with the queue reporting neither stopped nor errored and every counter zero. What is now bounded: the failure is on the receive descriptor side, the device says so itself, and the next step is the layout of Vmxnet3_RxQueueConf as this build reads it -- the ring sizes are written at conf+40 and conf+44 on the assumption that rxDataRingBasePA occupies conf+32, which is true of the current ABI and would put the sizes eight bytes wrong if this device uses the older one. The qualified profile is unchanged and make vmware-fusion-smoke passes on e1000e. The layout hypothesis is eliminated, with evidence. Writing the receive ring sizes at the older Vmxnet3_RxQueueConf offsets -- conf+32 and conf+36, as if rxDataRingBasePA did not exist -- gets activation refused with result 0x1. The device validates this configuration and accepts only the current layout, so the ring sizes it reads are the ones the driver intends, and the sizes are not why it cannot retrieve buffer descriptors. What remains is the descriptors themselves: the rings' addresses are accepted at activation, and reading sixteen-byte descriptors at those addresses is the step that fails. 2026-09-06 -- fixed, and it was never a VMXNET3 protocol question. The NIC now carries traffic end to end. The doorbell was landing on the SATA controller. VMXNET3_BAR0_VIRTUAL_BASE and AHCI_MMIO_VIRTUAL_BASE were both 0x330000000, chosen by hand in each driver. Storage probes first, so on any machine with a SATA controller -- which is every machine this row was ever measured on -- the network driver's BAR0 pointer was the disk controller's register window. Every doorbell write landed on a read-only capability register, and the device was never told a descriptor was ready. The read meant to prove the window was live returned 0xc0141f05: AHCI's CAP, six ports implemented, matching the pi=0x3f the disk driver had printed two lines earlier in the same log. Every measurement recorded above is consistent with it -- the queue not stopped, no error, no event, nothing ever taken, and re-ringing changing nothing. The device was healthy and was never spoken to. Device windows are handed out now rather than chosen. device_window_map() gives each driver a range from one arena, with a guard page between windows and the owner recorded, and a boot-time self-test requires that no two overlap. All five drivers -- nvme, e1000e, ahci, input and vmxnet3 -- take a window instead of naming one, so this cannot be written again. Two smaller receive defects went with it: the receive producer index was written as the slot just completed rather than the next slot to fill, and the refill generation never flipped at a wrap. Evidence, under QEMU: zero transmit timeouts where there were 284; network: DHCP lease ip=0a00020f mask=ffffff00 gw=0a000202 dns=0a000203 -- a real lease, not the fallback; SSH server: up and running; and ssh-keyscan completing a key exchange with the guest over the vmxnet3 card. And it is a ninety-second loop now, not a laptop. QEMU implements the same device: make qemu-x86_64-vmxnet3, with XAIOS_QEMU_X86_NIC selecting virtio, e1000e or vmxnet3 on the x86-64 runner. That is what found the collision, after a row that had spent months on measurements taken by hand on the one machine that has the real device. One correction to this row's own record. While chasing this I also "fixed" the receive queue configuration layout -- 16-bit ring sizes and no reserved field -- on a misremembering of Vmxnet3_RxQueueConf, and wrote it up as a second defect explaining VMware's Cannot retrieve the buffer descriptors per rx packet. It was not one. The published header has __le64 rxDataRingBasePA after the driver-data pointer and __le32 rxRingSize[2], exactly as this driver already had them; the change was reverted after checking the header rather than memory. The story was plausible and wrong, which is the reason to check a structure against its definition every time and not once. It was not confirmed on Fusion at the time of writing, which is the machine the row is about: the collision is present there too -- Fusion presents a SATA controller -- but the fix has been run under QEMU only. 2026-09-07 -- confirmed on Fusion, which is what this row was waiting for. The device-window fix was run on Fusion 26.0.0 with XAIOS_FUSION_NIC=vmxnet3, bridged onto the LAN, and the card carries traffic end to end there exactly as it does under QEMU: device-window: vmxnet3-doorbell ... at 0x350006000 and vmxnet3-control ... at 0x350008000 -- two windows out of the arena rather than one hand-picked address shared with AHCI, and they read differently (bar1_vrrs=0x1 bar0_at_vrrs=0x0), so they are genuinely different registers. Zero transmit timeouts where there were 284. network: DHCP lease ip=c0a81242 gw=c0a81201 is a real lease from the LAN's own router -- 192.168.18.66, not the 10.0.2.15 fallback -- and make vmware-fusion-network-gate passes on the card: ICMPv6 4/4 at 8.4 ms to a global SLAAC address, SSH on both families, and an SFTP round trip over IPv6 that came back identical. Two further defects the run found. network_device_name() had never been extended for VMXNET3 -- every other switch in kernel/dev/net_device.c handles all three kinds and that one fell through -- so a guest that had just leased an address over the card booted logging persistent network stack enabled device=none. And the Fusion gates could not be run against the card at all: BOOT_MARKERS named e1000e twice, so the first attempt timed out on a guest that had booted, leased and started sshd. The markers are read from ethernet0.virtualDev in the bundle being booted now, the way the vCPU count already was, and a card with no markers is an error rather than a silent check against another device's log lines. The qualified profile is unchanged and stays E1000E by choice, not by defect: XAIOS_FUSION_NIC still defaults to e1000e, and make vmware-fusion-smoke passes on it with the new markers.
F-03	Fusion network feature qualification	TESTING	Prove IPv6 TCP/UDP, outbound SSH/SCP, local DNSSEC interoperability, forwarding, and constrained loss/reorder behavior on a Fusion guest; existing QEMU evidence does not transfer automatically. The IPv6 half is unblocked, and what this row previously said about why was wrong. It recorded that a Fusion guest comes up link-local only, that its DHCPv6 solicit goes unanswered, and that this is "the hypervisor's NAT, not XAIOS". Two of those three were misread. The Fusion attachment is bridged, not NAT -- the guest sits on the real LAN and takes a real LAN IPv4 by DHCP -- and the network does offer IPv6: the host on the same wire holds a global SLAAC address from 2404:8000:1060:3a62::/64. The cause was in the guest. e1000e programmed its receive control as enable, broadcast-accept and strip-CRC, with an empty multicast table, so every multicast frame was discarded in the NIC. IPv4 never noticed, because DHCP is broadcast. IPv6 is multicast wherever it matters: a router advertisement arrives as 33:33:00:00:00:01, a DHCPv6 reply on ff02::1:2, a neighbour solicitation on the solicited-node group. The guest was soliciting a network that answered and could not hear the reply. "No usable IPv6 prefix after 3 solicitations" was a receive filter, not a network. With multicast reception enabled the guest autoconfigures a globally routable address from a genuine router advertisement -- IPv6: 2404:8000:1060:3a62:20c:29ff:fe90:dafd, the LAN's own prefix with an EUI-64 from its MAC -- and make vmware-fusion-smoke now carries that line. The DHCPv6 solicit still goes unanswered, which on a SLAAC-only network is correct and not a fault. The address is now reachable, and the second bug was the reason it was not. Both the neighbour advertisement and the ICMPv6 echo reply were sourced from g_link_local_v6 whatever address the peer had addressed. RFC 4861 requires a solicited advertisement to come from the solicited target, and a host that asked about a global address discards one arriving from a link-local address -- as far as it can tell, that answer is about a different machine. Ping fails the same way. So the guest was replying, correctly formed, from the wrong address, every time. Replies now come from whichever local address was addressed. Measured end to end on the bridged LAN: ping6 4/4 at 0.23 ms; the host's neighbour cache resolves the address to the guest's MAC and marks it reachable; SSH over IPv6 authenticates and runs a command (recovery status returning rescue=0 unclean_boots=0 boots=1); and an SFTP put/get round-trip returns a byte-identical file. That is the IPv6 TCP leg of this row, on a globally routable address, against a real router. Outbound IPv6 works too, once the guest was given a first hop. Configuring an address from a router advertisement and then ignoring the router that sent it leaves a host that can speak to its own link and nowhere else: the transmit path looked the destination up in the neighbour cache, and for an address on another network no neighbour ever answers, so an outbound connection waited forever rather than failing. The advertisement's own source address is now kept as the default router for as long as its Router Lifetime says, the advertised /64 defines what counts as on-link, and both the connect path and the flow-resolution path solicit the first hop rather than the far end. Measured across the public internet, guest to a machine in another country: the guest's own SSH client reaches root@2a01:4f8:c17:ecab::1's password: on the Hetzner host over globally routable IPv6 -- a TCP handshake and a full SSH protocol exchange, off-link, through the learned router. That is the outbound-SSH item of this row. IPv6 UDP and outbound SCP are done too. UDP was measured against a control rather than by watching a counter move: idle for six seconds the guest's udp_rx advanced by 3, and twenty datagrams sent to its global address on port 2222 advanced it by exactly 20. Outbound scp to the Hetzner host over IPv6 reaches authentication when the address is bracketed (root@[2a01:...]:/path); unbracketed it truncates at the first colon, which is the same ambiguity OpenSSH resolves the same way and not a defect. So this row's IPv6 leg is qualified: address, on-link reachability, TCP in (SSH, SFTP), UDP in, and TCP out (SSH, SCP) to another country, all on a globally routable address against a real router. What is left, and why. DNSSEC has a validating resolver configured and a deterministic local path covered by /bin/nettest, but interoperability over IPv6 cannot be shown here at all: dns_configure takes a uint32_t, so the resolver is IPv4-only by construction and pointing it at an IPv6 server needs a v6 transport in dns.c that does not exist. Forwarding and loss/reorder are bounded by the platform rather than by effort -- the Fusion guest has a single NIC, so there is nothing to forward between, and Fusion exposes no impairment control, so constrained loss and reorder have no way to be applied. Both need either a second Fusion NIC or a different environment, and neither is a matter of writing more driver code. One tooling gap found and not fixed: the guest's own ping and ifconfig parse and print IPv4 only, so ping <v6 address> reports target=0.0.0.0. The stack has IPv6 that its own shell cannot show. Read the log with care -- ndp: RA processed from ..., network: public IPv6 SLAAC address configured and ndp: RS/RA processing passed are self-tests against the 2001:db8::/64 documentation prefix, not the network. The line that means anything is the IPv6: address itself. 2026-09-06 -- the gate exists and passes. make vmware-fusion-network-gate builds the guest, boots it bridged, and checks the network from this host over the same wire: the guest takes a real LAN address by DHCP (192.168.18.66, and the gate fails if it lands on the 10.0.2.15 fallback, which is what a broken bridge looks like); it configures a global IPv6 address from a router advertisement (2404:8000:1060:3a62:20c:29ff:fe90:dafd); ICMPv6 answers 4/4 at 6.5 ms and this host's neighbour cache resolves the address to the guest's MAC and marks it reachable; SSH authenticates and returns a status on both address families; and a file put and fetched over SFTP on the IPv6 address comes back byte-identical. Negative control: the same reachability check against an address in the same prefix that nothing holds reports 0/2 and no neighbour entry, so a pass is not the tool agreeing with itself. What the gate does not claim, and says so in its own report: behaviour under loss or reordering, because the LAN is not a controlled link and a figure asserted about it would be asserting the weather; and outbound SSH from the guest to this host, which would need Remote Login enabled on the Mac -- the operator's decision, not the gate's.
F-04	Fusion snapshot and sustained-load qualification	IN PROGRESS	Snapshot and resume semantics are now defined by a gate that demonstrates them. make vmware-fusion-snapshot-gate states the guarantee as three properties and requires the machine to exhibit each: a snapshot is a point in time (data committed before it survives a revert, data committed after it does not -- both halves, since a revert that kept everything would pass a check looking only at the first); a revert lands on a filesystem the guest trusts (the volume loads, no checksum errors, and the boot is not counted unclean); and a suspend is not a power cut (the lifecycle record is unchanged across suspend and resume, which matters because three unclean boots put a machine into rescue mode -- a suspend that counted as a crash would do it in three). Nine checks, all passing. Taken with the guest powered off, and that is a decision. A snapshot of a running machine carries its memory, so reverting resumes rather than reboots: the guest prints no boot markers and never remounts anything, and the first version of this gate hung waiting for a readiness line that had already been printed before the snapshot was taken. Durability across a snapshot is a property of what reached the disk, and a powered-off snapshot tests exactly that with nothing else mixed in. It found a defect: B-25. After a revert the guest intermittently boots clean and then refuses every command while SFTP against the same guest works perfectly. The gate reads files over SFTP for that reason -- measuring the property it exists for rather than failing on an unrelated fault sitting in front of it -- and reports the condition rather than papering over it. Remaining: long-duration storage and network load, repeat-boot at volume, and crash recovery against generated VMDKs. None of that is blocked; it is simply not done. 2026-09-06 -- repeat boot at volume, after fixing three things in the bench that made it impossible. vmware-fusion-boot-soak --boots 40 now runs 40 boots, 40 clean shutdowns, no fatal marker in any console and no boot in rescue mode, at about 15 seconds a boot. Getting there needed three harness defects fixed, each of which had been reporting the bench's own damage as the guest's: (1) build-vmware-fusion.sh never recreated the durable disk -- vdiskmanager -c will not overwrite -- so every build inherited whatever the last run left, including a lifecycle record latched into rescue mode that no later boot clears; (2) the soak ran only the Fusion packaging step, which repackages whatever image is in build/, so the VM booted with somebody else's authorized key and every SSH command was refused -- the shutdown never arrived, each boot was hard-stopped, and rescue latched on the fourth; (3) a shutdown that works closes the connection under the client, so ssh exits non-zero on the very command that succeeded and the soak counted it as a failure. It now sends the command until the machine stops, and what says the shutdown worked is the machine stopping. B-25 was not reproduced by any of the 40, which is expected: it appears after a snapshot revert and this exercises the boot path, not that one. Remaining: long-duration storage and network load, which is a different shape of run from repeat boot.
F-05	Fusion entropy and production-credential boundary	CLOSED	Fusion 26H1 exposes neither EFI_RNG_PROTOCOL nor AArch64 RNDR in this profile, so current images use a unique local development seed. Production requires an operator-approved entropy/key-provisioning design and credentials -- that half is still theirs and is what keeps this blocked. The engineering half is done: the boundary now exists, where before it could not even be observed. The loader copies a seed file off the EFI System Partition and then overwrites it from EFI_RNG_PROTOCOL if the firmware has one. On a machine where it does not, what survives is a file baked into the image -- identical on every boot and on every machine built from that image -- and the kernel logged entropy: EFI RNG seed accepted for both, because the seed is the same size either way and nothing carried the difference. A development seed was indistinguishable from a hardware one in the record, which is worse than having no record. The boot structure now carries the provenance alongside the seed, in what was reserved padding so the layout is unchanged, and the kernel reports it: entropy: source=hardware under QEMU where the firmware has an RNG, and entropy: DEVELOPMENT seed file accepted with source=development-seed-file on Fusion. Both were run, not argued. entropy_is_production_grade() makes the question askable in code, and host-key rotation asks it -- minting a key on development-grade entropy now says so, naming the key as reproducible from the image it was built into. It warns rather than refuses on purpose: refusing would take working machines off the network over a property they have always had. What turns this into a gate is the operator decision this row is blocked on -- which entropy source production requires -- after which the warning becomes a refusal in one place. 2026-09-06 -- the boundary is gated on every machine, and gating it found a machine on the wrong side of it. RISC-V reported entropy: source=none while a working virtio-rng sat on its bus and served every entropy_read: the pool the provenance report describes was simply never seeded from it. A machine that has a source and says it has none is the exact failure this work existed to end, and it was invisible because nothing asserted the line. The pool is now seeded from a random device when one is present -- always mixed in, since more real entropy is never worse, and named as the source only when nothing better already was, so a firmware RNG still reports hardware. The new value is device-rng, counted as production grade because it is a source the machine asked the host for and received, which is the distinction this predicate draws: what it must refuse is a file baked into an image, identical on every copy. Now asserted, not observed: source=hardware on aarch64 and x86_64 under QEMU, device RNG seed accepted and source=device-rng on RISC-V, and on Fusion -- which has neither a firmware nor an architectural RNG -- both DEVELOPMENT seed file accepted and source=development-seed-file. Four machines, each held to the truth about itself. Still blocked on the same thing: which entropy source production requires, and the credentials, are the operator's to decide; after that the warning in host-key rotation becomes a refusal in one place. 2026-09-06 -- the decision is made and the warning is now a refusal. The question this row was blocked on -- which entropy source production requires -- is answered: a source the machine asked a device or its firmware for, and never a file baked into an image. entropy_is_production_grade() already drew that line; what was missing was anything that acted on it. xaiosctl auth host-key rotate now refuses on development-grade entropy rather than minting and warning. The old reasoning for warning was that refusing would take working machines off the network, and it does not survive looking at what rotation does: rotation is not what gives a machine its first host key -- sshd mints that at boot when none is stored, and this path does not touch it -- so refusing leaves the existing key in place and the machine exactly as reachable as it was a second earlier. What it declines to do is mint a new long-lived identity that anyone holding the image can derive, at the moment an operator has deliberately asked for a fresh one, which is the moment they are least likely to read a warning because they have just been told it worked. The cost of refusing is nothing; the cost of warning was a key an operator believes is new and is not. The first-boot mint is deliberately left alone, because refusing there would leave a machine with no host key and no SSH, and the operator who would fix that is the one who cannot get in. It names its provenance instead, in the console next to the kernel's own entropy: source= line. Gated on every boot, on all three architectures: the kernel's admin-control self-test swaps the recorded provenance -- the label only, never the pool -- and requires the decision to come out DENIED for a seed file and for no source at all, and OK for a firmware RNG and for a device RNG. admin-control: host-key rotation refuses development-grade entropy and permits a real source. It tests the decision rather than a booted rotation on purpose: on every machine this project can boot in a test the answer is always "permitted" -- QEMU's firmware offers an RNG, its bus offers a virtio-rng, and a RISC-V guest with neither refuses to start SSH at all (SSH server: not running error=2001, verified) -- so a booted test would assert nothing, and Fusion, the one machine that really has a development seed file, cannot be a gate that runs everywhere. What remains is a platform limitation, not a blocked task: a Fusion guest has no entropy source, so it cannot rotate its host key until VMware exposes one or the operator provisions one. That is now a refusal an operator can see and act on, which is what this row existed to produce.
F-06	Fusion release-version coverage	DEFERRED	Postponed deliberately; nothing external blocks it. Qualify each additional Fusion release independently. Fusion 26H1 evidence is not a compatibility claim for earlier/later releases, x86_64 guests, or physical Apple hardware.

Apple Virtualization.framework ARM64 remaining work

XAIOS boots to a login on this platform with xaibootFS on a durable volume, DHCP IPv4, SLAAC IPv6, SSH and all four vCPUs online, and the Mac can ssh into the guest over vmnet through platform/virtualization-framework/vmnet-helper, which is the only route in: the built-in NAT attachment delivers no host-initiated frame, and bridging needs an entitlement V-03 also waits on. make vz-gate checks that boot and writes build/vz-gate.json. It is a development target: the gate needs macOS on Apple Silicon and a signed harness, so it cannot run in CI and its result is not qualification evidence.

ID	Item	Status	Evidence / remaining gate
V-02	MSI-X delivery for virtio on PCI	TESTING	Exercised by attaching QEMU's virtio devices on PCI, with modern identifiers and the 32-bit window, against a real translation service: every device on the bus receives a distinct vector. Three defects were fixed to get there -- one translation table shared by all devices, identifiers reissued to a second device because the first polls and never registers a handler, and an assertion on any BAR above 512 GiB. Physical ARM PCIe hardware remains the qualifying case; Virtualization.framework still has no ITS, so its queues stay polled.
V-03	Globally routable IPv6	TESTING	The NAT attachment advertises the unique-local prefix fd4a:25c::/64, so no globally routable address is on offer. A bridged attachment would carry real IPv6 but needs the com.apple.vm.networking entitlement, which Apple issues only with a provisioning profile; ad-hoc signing cannot provide it. That is unchanged and is what keeps this blocked. What has changed is that the blocker is now known to be only the entitlement. The guest half was never proven, and while e1000e discarded every multicast frame it could not have worked on any attachment, entitled or not -- no router advertisement could reach the stack. That is fixed and demonstrated on the one attachment available here: a bridged Fusion guest on the same LAN autoconfigures a globally routable address from a real router advertisement. See F-03. So what the entitlement would carry, when it exists, is a stack shown to take a routable address from a network that offers one, rather than an untested assumption. 2026-09-06 -- the route round the entitlement is built and waits on one privileged command. vmnet-helper now takes --mode bridged, which asks vmnet for VMNET_BRIDGED_MODE on a named host interface and sets no address range, because on a bridge the addresses come from the LAN's own DHCP server and router advertisements. This needs no entitlement: VZBridgedNetworkDeviceAttachment needs com.apple.vm.networking, vmnet needs only root, and only the eighty-line relay runs as root -- the virtual machine does not. make vz-bridged-gate boots the guest onto that socket and checks what routable means: a lease from the LAN rather than the 10.0.2.15 fallback, a global IPv6 address from a real router advertisement, ICMP answered on both families from this host, and the guest's address being inside this host's own /24 -- so a guest answering on vmnet's private 192.168.201 range, which is reachable and not bridged, fails rather than passes. What is left is one command, and it is the operator's: sudo ./build/vz/vmnet-helper --socket "$PWD/build/vz/vmnet.sock" --mode bridged --interface en0, left running in another terminal. The gate prints exactly that and stops when the socket is absent; nothing in it asks for a password or tries to acquire privilege. 2026-09-06 -- run, and it works. The entitlement was never the only way. With the relay started by the operator, make vz-bridged-gate passes: the guest takes 192.168.18.70 by DHCP from the LAN this Mac is on (the host holds 192.168.18.25 on the same /24, and the gate requires that -- a guest on vmnet's private 192.168.201 range is reachable and not bridged), and configures 2404:8000:1060:3a62:459:7dff:feab:609f from the LAN's own router advertisement, in the same /64 as this host's global addresses. Reachable from the Mac on both families: ICMPv4 4/4 at 5.9 ms, ICMPv6 4/4 at 11.2 ms. So a Virtualization.framework guest holds a globally routable IPv6 address without com.apple.vm.networking, which is what this row was blocked on for months: the entitlement is required by VZBridgedNetworkDeviceAttachment and not by vmnet, and only the relay runs as root. What keeps this out of an unattended suite is that the relay is privileged: the gate prints the command and stops rather than asking for a password, so this is evidence a person can reproduce in two commands and not something CI can run.
V-04	Multi-vCPU qualification	IN PROGRESS	Secondaries genuinely run here now, which they never did before: PSCI starts them with translation off, where exclusives are unsupported, so the atomic each one used to announce itself aborted, and everything they published went to memory the boot CPU was not reading. Every boot reported online cpus=1/4 and most panicked. With that window made coherent, boots come up 1/1, 4/4 and 8/8, the secondary worker barrier passes at each, and ten consecutive eight-vCPU boots produce byte-identical smptest signatures -- worker sets, kernel-dispatched worker groups and EL0 create/join -- with no panic in any of them. make vz-gate boots four vCPUs and requires 4/4. What remains cannot be answered here: this host has eight cores against a 128-256 core target, the platform offers no control over interrupt affinity, and none of this is sustained-load evidence. 2026-09-06 -- the sustained-load half has evidence. XAIOS_VZ_STRESS_RUNS=12 make vz-stress-gate boots twelve times at eight vCPUs, each boot running /bin/smpstress with threads pinned across the cores: 1,205,201,984 contended increments across the twelve, every one of them exact. Per run the count lands between 99.7M and 100.9M -- a 1.2% spread, which is scheduling and not arithmetic -- with the contended counter and its neighbouring words correct, create/join churn deterministic, and no panic and no rescue boot in any of them. Each run gets a fresh durable volume, so no run inherits another's state. The boundary is unchanged and is not something more runs can fix: this host has eight cores against a 128-256 core target, and the platform offers no control over interrupt affinity. What is now evidenced is that eight vCPUs under sustained contention are correct and repeatable here; what is not evidenced is anything about a machine with more cores than this one has.
C-01	Shared kernel state under genuine parallelism	TESTING	Addressed subsystem by subsystem, because the right fix differed per file. The network stack, service records and CPU-AI runtime took a reentrant guard on their syscall-reachable entry points -- reentrant because ten of the network stack's exported functions call other exported ones, which a plain lock at each entry would deadlock on. The resolver shares the network guard rather than holding its own, since it calls tcp_open/send/recv/close while network_poll_tick calls back into its timers; a separate guard there was a lock-order inversion, caught and removed before it could bite. security.c and agent_protocol.c hold no tables at all, so their 48 audit totals became atomics instead: guarding capability checks on the syscall path would have cost far more than it bought. vfs_xaifs.c already locked; update, ai_cell, persistence and sandbox have no syscall entry points and are covered by guarded callers. Guard order is service before network, one direction, recorded on the primitive along with the rule that it must never be taken from interrupt context. What remains is not correctness but cost: these are coarse locks, network syscalls now serialise against each other and the poll path, and no controlled measurement of that exists yet. The cost of those guards is C-03, and the work to make them finer is C-02; neither is a reason to have waited on correctness.
C-02	network_stack.c state escapes its module	TESTING	The obstacle to finer locking was never the lock: it was that tables handed out their rows. The socket map returned interior pointers across the syscall boundary, where callers dereferenced them after the guard had been released -- a live race once secondary CPUs ran -- and now returns a copy. The listener registry leaked rows to seven functions inside the module, all of which now hold its own guard. No exported function returns a pointer into module state any more, and the interior lookups that remain -- flows, queues, packet descriptors -- are reached only through guarded entry points. That is the whole of this item. Splitting those tables further was left open pending C-03, and C-03 has since measured it: the socket path costs the same per operation at eight threads as at four, and giving the listener registry its own guard rather than sharing the stack's made no measurable difference, so that split was removed rather than extended. Finer locking is therefore not scheduled -- not because it is hard, but because nothing measured asks for it. Reopen if a workload shows the coarse guard costing something.
C-03	The socket path scales; the finding that said otherwise was noise	TESTING	Measured on a quiet machine, three runs per configuration. Socket bind/close costs about 40us per operation at four threads and the same at eight, so throughput rises with cores. That holds whether the listener registry has its own guard or shares the stack's -- 38,761/40,825/32,400 against 41,827/35,453/41,751 at four threads -- so the split bought nothing measurable and has been removed. Both are roughly ten times faster than the 437us that opened this item, which was recorded while vmnet-helper held a core busy and an unrelated application ran: that measurement was contention with the host, not serialisation in the stack, and the refactor it justified was built on it. What survives is correctness work that never depended on the number: the socket map returns a copy instead of a pointer into the table, and readers cover their use of a row rather than only the lookup. Nothing here is a performance claim under the benchmark contract.
V-06	Graphical console	TESTING	Implemented. The platform's GOP reports PixelBltOnly with a zero framebuffer base, so firmware leaves nothing to draw into and GOP->Blt() does not outlive ExitBootServices -- but the display device is on the PCI bus regardless, and kernel/dev/virtio/virtio_gpu.c now claims it: display info queried, a 2-D resource created, the framebuffer attached page by page (1000 pages for 1280x800, because heap pages are not physically contiguous), a scanout pointed at it, and a transfer-and-flush after each draw, since the device copies on demand rather than scanning continuously. boot_ui adopts the result through a callback so it stays independent of which device supplied the buffer. The flush is no longer whole-screen: boot_ui accumulates a dirty bounding box across every drawing primitive -- they all reach the buffer through fb_rect, so one mark covers them and none can be forgotten -- and presents only that region, skipping the device entirely when nothing was drawn. Scoping the flush alone changed nothing measurable, because the boot status repainted the whole screen on every update; that clear is now full-screen only on the first draw, since nothing else is on screen during boot. Counted over a full --gui boot: 10 presents, 3,143,680 pixels sent against the 10,240,000 a whole-screen flush per present would have sent, a 69% reduction. What a person sees is now checked mechanically rather than by an operator: make qemu-framebuffer-gate boots with a virtio-GPU attached, waits for the login prompt and reads the scanout back through QEMU's screendump, which is the same surface a viewer is shown. Doing it found a defect that nothing inside the machine could see. boot_ui_update draws and presents; boot_ui_handle_control only drew, so the last four stages of boot -- 95%, 100%, the ready summary carrying the machine's addresses, and the handover to the terminal -- were written into the framebuffer and never transferred to the device. A machine sitting at a login prompt displayed a progress bar stopped at 90% for as long as it was left there, while the serial log reported every one of those stages completing. Captures at the prompt and thirty seconds later were byte-identical. With the presents added the screen shows the handover: the IPv4 and IPv6 addresses, SSH SERVER: UP AND RUNNING (TCP/22) and a cursor at XAIOS LOGIN:. The gate requires both halves -- no progress bar left on screen and pixels actually drawn -- because either alone passes for the wrong reason: a dead display has no bar either. Measured against a real pre-fix capture the two states are 7200 bar pixels against 0, so the threshold is not close to either. Remaining: this reads QEMU's scanout, not a physical display, and not Fusion's or Virtualization.framework's.

Core OS, network, and SSH phases

ID	Item	Status	Evidence / remaining boundary
N-F3P	Physical SSH/network security qualification	IN PROGRESS	Consolidated QEMU network/SSH readiness evidence is available through make qemu-qualification-readiness; physical lossy-link, sustained-load, side-channel analysis, and independent SSH/cryptography review remain open. QEMU evidence cannot close this item.

Storage phases

Phase	Status	Evidence / remaining gate
S-11P Physical production NVMe qualification	IN PROGRESS	Consolidated QEMU NVMe and crash-recovery evidence is available through make qemu-qualification-readiness; named physical devices must still pass queue scaling, interrupt affinity, FUA/flush/discard semantics, reset recovery, power-loss durability, sustained-load, and performance gates. QEMU evidence cannot close this item.
S-12 Production xaiFS trust-root and signing-key custody	BLOCKED	Offline trusted-replica payload repair is implemented and QEMU/hosted-tested. Production trust-root enrollment, private-key custody, replica authorization, and rotation decisions require named operators and deployment credentials.

Distributed AI server phases

Phase	Status	Exit gate
D-05 Real local inference	NOT STARTED	Real Qwen correctness, typed state, scheduling, cancellation, backpressure, and metrics.
D-06 Authenticated cluster control	TESTING	Hosted tests cover directional HMAC framing, receiver/epoch/nonce validation, replay rejection, and membership transitions. The QEMU-testable tranche is done. make qemu-cluster-two-node-gate now runs join, partition, recovery and ownership across two independent XAIOS guests, each phase arriving on its own TCP connection rather than inside one exchange -- the second machine has to be ready for the first on its own schedule, which is the asynchrony that was missing. Membership moves from frames that actually arrived: xaios_cluster_open marks a sender ONLINE for any opcode but LEAVE and OFFLINE for that one, so nothing asserts its own bookkeeping. What is checked is a relationship between the two logs rather than anything either says alone, which is why it is checked in the gate and not in the guests: both machines name the same owner for one fixed expert while both are online (owner=2), each names itself while partitioned (1 and 2), the original owner returns when the peer does, and the ownership version advances across all three. That combination is hard to satisfy wrongly -- a node caching its first answer passes the first and third and fails the second, and one recomputing from stale membership fails the third. The version is local and deliberately not the wire epoch, because open refuses a frame whose epoch is not its own, so bumping it to mark a membership change would stop the two ends speaking at all. Remaining: this is two nodes. Failure detection is a LEAVE that is sent rather than a peer that goes silent, there is no heartbeat deadline, and three-node quorum questions do not arise at two.
D-07 Distributed placement/execution	IN PROGRESS	Hosted tests cover deterministic expert ownership, grouped routing, simulated node-loss rerouting, and stable node/expert reduction. End-to-end distributed activation execution depends on D-05 real local inference and D-06 guest transport; it cannot be closed by hosted placement tests alone.
D-08 Benchmarks/diagnostics	IN PROGRESS	QEMU benchmark telemetry and a hashed qualification-readiness report are implemented; physical metadata-rich NUMA, bandwidth, PMU, thermal, storage, network, and redacted support-bundle evidence remain.
D-09 Production inference service	NOT STARTED	Authenticated API, streaming, cancellation, saturation, loss, and long-lived tests.
D-10 Support qualification/cleanup	IN PROGRESS	Documentation contracts and the consolidated QEMU qualification-readiness gate exist; physical, model, cluster, thermal, PMU, and durability qualifications remain.

Qwen 3.8 implementation

Item	Status	Acceptance
Pin immutable official config/tokenizer/SafeTensors and parity corpus	NOT STARTED	Hashes and source revisions recorded.
Streaming SafeTensors/config/tokenizer importer	NOT STARTED	Bounded RSS and deterministic package output.
Package-owned tokenizer	NOT STARTED	Trusted tokenizer IDs match.
Official architecture probe and ordered configuration-derived layer plan	NOT STARTED	Unknown fields fail closed.
Scalar embedding, RMSNorm, and first projection	NOT STARTED	Python reference parity.
Every configured attention/recurrent/convolution operator, position encoding, FFN, residual, norm/head	NOT STARTED	Complete-layer and prefill-logit parity.
Separate prefill/decode plans and real per-layer state	NOT STARTED	State and reload continuity.
32-step deterministic decode	NOT STARTED	Exact trusted continuation within documented tolerance.
Physical AVX2 and tiled prefill/verification kernels	NOT STARTED	Physical differential and performance artifacts.
Native model-executing macOS process and optional Metal	NOT STARTED	Real model plan runs end to end; CPU fallback remains authoritative.
AVX-512/VNNI/AMX, SVE/SVE2, persistent worker gangs, NUMA autotuning	NOT STARTED	Capability canaries, scalar differential, and physical evidence.
Typed paged state, prefix COW, ragged batching, exact speculation	NOT STARTED	Target-only and speculative deterministic outputs match.

Later model work

Item	Status	Acceptance
Separate kimi_k3 adapter from immutable official config	NOT STARTED	Config/tensor roles reject unsupported fields.
K3 KDA, Gated MLA, AttnRes, exact top-16 routing, shared experts, SiTU, MXFP4	NOT STARTED	Scalar operator/router/expert parity.
K3 independently addressable expert shards and async residency/prefetch	NOT STARTED	Authoritative routing is unchanged by prediction.
Real K3 text checkpoint	NOT STARTED	Tokenizer/operator/router/target-token and production-width physical gates.
K3 MoonViT-V2 and multimodal pipeline	NOT STARTED	Separate golden image/text cases.
DeepSeek V4 Flash 0731 source verification	BLOCKED	Maintainer-approved immutable official source.
DeepSeek adapter and parity suite	BLOCKED	Depends on verified source.
Multi-terabyte sparse allocators and large pages	IN PROGRESS	Hosted model packages represent sparse offsets above 100 GiB; both QEMU targets cover 2 MiB mappings and x86_64 covers a 1 GiB leaf plus targeted SMP TLB invalidation. Physical capacity and performance qualification remain.
SRAT/SLIT/HMAT placement policy and local/remote byte telemetry	IN PROGRESS	The two-node x86_64 QEMU gate validates SRAT/SLIT/HMAT parsing, usable-memory intersection, deterministic preferred-node policy, node-local allocation, and local/remote byte accounting. Physical locality/performance qualification remains.
AI Cell/secondary-CPU real inference dispatch	NOT STARTED	Real model work executes on leased workers.
NUMA/machine expert ownership and stable failure-aware reduction	IN PROGRESS	Hosted tests validate deterministic owner selection, grouping, simulated owner failure, and stable reduction. Real NUMA/machine transport, remote activation execution, and multi-QEMU exactness remain.

Open decisions

ID	Decision	Status	Required before
OD-001	Select first physical Apple/ARM target and firmware/storage/NIC boundary	NOT STARTED	Physical ARM support.
OD-002	Select representative AVX2 Intel desktop and hybrid-core/device baseline	NOT STARTED	Intel desktop support.
OD-003	Select Xeon generation, sockets/NUMA, memory, NIC, and NVMe	NOT STARTED	Xeon support.
OD-004	Provision production update/xaiFS trust roots and define custody/authorization procedures	BLOCKED	Rotation, revocation, offline recovery, and interrupted-activation rollback are implemented; private operator keys and process are required before untrusted deployment.
OD-005	Define SSH fleet limits, identity, audit retention, lockout, recovery	NOT STARTED	Production SSH exposure.
OD-006	Define supported NVMe/FUA/flush/discard/repair/power-loss contract	NOT STARTED	Physical persistent deployment.
OD-007	Pin official immutable Qwen 3.8 fixtures	NOT STARTED	Qwen implementation.
OD-008	Pin official Kimi/DeepSeek sources	BLOCKED	Corresponding adapters; DeepSeek exact label is unresolved.
OD-009	Select expert-parallel interconnect and failure/ownership model	NOT STARTED	Cluster inference.
OD-010	Define names, quality reporting, telemetry, and acceptance for opt-in approximate modes	NOT STARTED	Any approximate mode.

Risk register

Risk status TESTING means mitigations exist but the risk remains open and is checked continuously.

ID	Risk	Status	Mitigation / closure gate
R-001	QEMU timing presented as hardware performance	TESTING	Evidence vocabulary and benchmark contract; close only with continued claim audits.
R-002	Documentation drift	TESTING	One tracker, make docs-check, and live-Wiki parity. check-doc-freshness.py now also fails the build on the two claims that expire quietly: an evidence commit of ours that has fallen far behind HEAD without saying so, and a review date on a page that git shows was edited afterwards. Three such claims were found expired in a single session -- a page saying a target had no automated gate months after two were added, a stale review date, and an evidence commit quoted as current from a hundred commits back -- so the residual risk is prose that is wrong in ways no pattern can see.
R-004	Unreviewed SSH exposure	TESTING	Passwords off by default, bounded limits, OpenSSH/FreeBSD gates; independent review remains.
R-005	Fixture keys used as production trust	TESTING	Fixtures are labeled; OD-004 blocks production trust.
R-006	Storage durability inferred from sparse/QEMU tests	TESTING	Passing emulated async-NVMe and crash-recovery gates remain separate from physical S-11P and trust/repair S-12; only physical evidence can establish durability.
R-007	Parser arithmetic or ownership error	TESTING	Checked arithmetic, malformed tests, sanitizers, immutable readers, fuzzing.
R-008	Interfaces advertised as model support	TESTING	Separate progress and support-boundary columns plus golden gates.
R-009	SIMD selected from CPUID alone	TESTING	OS-state checks, known-answer canaries, and scalar differential tests.
R-010	Bounded fixture limits treated as server-scale targets	TESTING	Runtime-sized CPU/NUMA structures and explicit remaining bounded stores.
R-012	Repository Wiki diverges from live Wiki	TESTING	Versioned Wiki source, post-push byte comparison, and docs checks.

Evidence gates

The default status-changing evidence set is documented in Testing XAIOS. At minimum, source changes require the smallest relevant compile/hosted/QEMU gates; documentation changes require layout, status, JSON, link, and live-Wiki checks. A failed required gate changes the affected item to FAILED until a passing rerun is recorded.

GitHub issues and milestones may provide discussion and execution history, but their descriptive status must link back here rather than becoming another independent tracker.