ARM64 port, stages 0 to 3: shared groundwork, aarch64-unknown-toyos with std and the userland, and the loader and kernel reach the PL011 on virt

[Japabu]

The ARM64 port (issues/kernel/toyos-runs-on-arm64.md), stages 0 to 3, as one PR: the groundwork shared with x86, the aarch64-unknown-toyos target with std and the userland, then the UEFI loader and the kernel reaching the PL011 on QEMU virt under HVF. AArch64 links through rust-lld (owner's ruling, 2026-09-26); x86-64 links as it did.

What a boot does now, on this M4 Pro: qemu-system-aarch64 -M virt,gic-version=3 -accel hvf with AAVMF loads the loader off the USB stick. The loader reads ROOT through firmware (ROOT now carries the AArch64 userland), says at which EL firmware handed it the CPU (at EL2 with HCR_EL2.E2H and ID_AA64MMFR4_EL1.E2H0, refusing by name a CPU whose E2H is RES1), and hands off. The kernel drops from EL2 when entered there, writes its control-register declaration whole, turns on the loader's tables, installs its vectors, finds the PL011 through SPCR, and prints the boot log, the memory map, the MADT's GIC structures and the GTDT's timers. It then stops at the first item a later stage owns, with an EARLY PANIC on serial and on the ramfb panel:

• under HVF: RNDR, which HVF does not expose (virtio-rng is stage 6);
• under TCG -cpu max: the kernel's own page tables (stage 4).

Every stand-in for later work is an owed! that panics naming its stage; none returns a guess.

Stage 0: the shared groundwork, on x86

• One Arch (src/arch.rs) names every triple, QEMU binary, firmware, CPU and accelerator, and now which linker an architecture's guest binaries use (links_through_toyos_ld) and QEMU's -boot for its firmware. The build, cargo run, CI and the harness read it.

• toyos-elf takes a machine: EM_AARCH64 and R_AARCH64_RELATIVE, so the loader reads an AArch64 kernel. toyos-ld is byte for byte main's (see "The linker").

• The kernel's arch/ is x86_64/ behind one selector (arch/mod.rs):

  • the syscall handlers moved out; only the gate is x86;
  • one IrqGuard replaces three hand-rolled ones, and fixed their nomem compiler-ordering bug;
  • one MSI doorbell;
  • the PC's own devices (i8042, I/O APIC, TCO, CMOS RTC, VT-d), the page tables and the scheduler's Hw boundary live under arch/x86_64/, and generic code names each by concept (keyboard_controller, irqchip, trap, iommu_unit, cpu::counter, …).

• Mmio carries writel/readl ordering (arch::barrier: a compiler barrier on x86, DMB OSHST/OSHLD on AArch64). Every descriptor-then-doorbell site names its barrier (dma_wmb/dma_rmb). Three ordering bugs fixed on the way:

  • NVMe read a completion's body before its phase tag was known new;
  • xHCI's TrbRing::put wrote the cycle bit with the body;
  • xHCI's event read did the same in reverse.

• The architecture rules (src/sourcegate.rs, ARCH_RULES):

  • assembly only in an architecture's module;
  • target_arch only there or in a selector;
  • no path into arch::x86_64::/arch::aarch64:: from generic code;
  • none of the three in a pure crate.

  core::arch/std::arch count in any spelling a line scan can resolve: the path, a use … as of it, an arch element of a core::{…} group. A glob or a rename of core/std itself is refused outright, outside the places: use core::*;, core::{*}, use core as k;, extern crate core as k;, core::{self as k}, use {…, std as k}. What those bring into scope is a question for name resolution, which a line scan does not have; following each alias to a later arch would be one more pattern per spelling and never sound, while refusing the import is, and no file outside an arch module has another use for either (the whole-tree rule is green). A rename counts only in an import item, so core as u32 on a variable and crate::core as c are not reds; the fixture holds both.

  Each rule has a fixture test that plants a violation and reds naming the rule and its places. libc, toyos-window and metalprobe now keep theirs in arch/ modules (stage 1). The guest probes are the declared rows left (issues/build/assembly-outside-an-arch-module-in-userland-and-guest-probes.md).

• The Relaxed audit: all 761 lines naming Relaxed under kernel/src (84 files) read.

  • Changed: the panic console's published framebuffer descriptor was a seqlock over a plain cell, a data race. It is now atomic words (drivers/panic_console/published.rs) with a loom model.
  • Three publications that promised an order they did not have: panic.rs's crash evidence, hardlockup's spin record, and the USB fault staging.
  • The serial backend's lock (drivers/serial_lock.rs): a lost try_lock once built the guard it had lost and released the holder's lock when it dropped. The lock is a file kernel-loom compiles, and kernel-loom/tests/serial_lock.rs models it.
  • Mmio's contract says a write orders prior stores only, as writel does: a doorbell that hands back entries this CPU read is ordered by dependency alone.

Stage 1: aarch64-unknown-toyos, std and the userland

• The target: the rust pin is c34ecdf0ab6, this branch's 851c6bfcaa8 merged with Where everything lives: the layout as ruled, and its first stage #531's 80ea645f83b, and merged into toyos-inbox as 2434fb9d1bc. aarch64-unknown-toyos is the ToyOS base options with +v8a, 128-bit atomics and rust-lld (GNU flavour). Outline atomics are off: their helpers ask the OS through an auxiliary vector ToyOS does not have.
• std (fork):
  • _start reads argc/argv off the stack and ends the frame chain.
  • TLS is variant I: TCB at TPIDR_EL0, DTV in its first word.
  • No TLS-descriptor resolver: nothing on AArch64 loads a shared library yet, so fork commit 851c6bfcaa8 deleted the one this branch had written with no caller, and the kernel refuses R_AARCH64_TLSDESC by name. An executable is refused on its count: RelaCounts::for_executable returns ExeRefusal::TlsDescriptor (or TooLarge), and it is the only way to the ExeReservation whose capacities parse_rela_entries reserves, so the kernel cannot skip the refusal and still reserve. A library is refused in rela::validate (RelocError::TlsDescriptor). The resolver returns in the port's stage 5 with its loader half and a dlopen test.
• libc (userland/libc/src/arch/): _start, memcpy/memmove/memset and the square roots, one module per architecture, with their AArch64 versions (pair loads/stores with a byte tail, fsqrt). toyos-libc-copies compiles that module for the host and holds every copy, fill and square root against Rust's own; each host architecture checks its own module.
• The build:
  • GUEST_TARGETS gains the AArch64 userland target. Every architecture has a userland, so USERLAND_ARCHS and the plan's Userland switch are deleted: its Absent arm was unreachable and without_userland uncalled.
  • cargo run -- --arch aarch64 --build-only builds std, libtoyos_c and the userland for AArch64 and puts them on ROOT. This includes toyos-ld and toyos-cc as guest programs.
  • Left off an AArch64 ROOT by name at build time (NOT_YET_BUILT): calc, snake and doom. softbuffer's and winit's toyos forks resolve the published toyos-window 0.2.0, whose framebuffer is x86-only (issues/build/the-toolkit-forks-resolve-an-x86-only-toyos-window.md). Existing Rust GUI apps on ToyOS: iced on one winit backend, paced redraws, forks on one branch per base #528 moved those forks and is merged here. Whether they now build for AArch64 was not measured, so the entry stands.
  • toyos-window's and metalprobe's scanout drain went into arch modules (SFENCE; DSB ST), so toyos-window is 0.19.0: main's is 0.18.0 (Existing Rust GUI apps on ToyOS: iced on one winit backend, paced redraws, forks on one branch per base #528).
• A worktree builds the compiler its fork names (src/compiler.rs). check_compiler refused a fork checkout whose compiler/ differed from the primary's, which contradicted the landed rule that every worktree builds the toolchain its own sources name.
  • Where the fork's compiler/ is the one the primary recorded, the worktree uses the primary's stage2.
  • Otherwise bootstrap builds a stage-2 compiler, host only, in the worktree's own fork checkout (build/toyos-compiler), with rust-lld. It is placed at rust/build/compilers/<key>/.
  • The key is the identity (src/identity.rs) of compiler/, src/bootstrap, src/tools, src/stage0 and Cargo.lock, the src/llvm-project commit, and the recipe. It is content only, so committing what was built as local changes is the same compiler.
  • A primary with no record of which compiler its stage2 is is refused by name; it used to read as empty and send every worktree to build its own.
  • The sysroot key already named the compiler's identity, so a sysroot is cloned from, and compiled by, the compiler its worktree names.
  • Nothing of the primary's is written: not its stage2, not its record, not the rustup toyos link (a sysroot is named by directory). The global lock is not taken.
  • A compiler key's lock (buildlock::Keyed, shared with sysroots) orders before the sysroot key's. --worktree remove and every placement sweep unnamed compilers; the one in use is held and stays, so an edit loop keeps one compiler, not one per edit.
  • hosted-rustc is refused in such a worktree: the hosted rustc is the primary's.

The linker

By the owner's ruling, AArch64 links through rust-lld and toyos-ld is frozen. This branch's toyos-ld work is reverted by a new commit, leaving toyos-ld identical to main: the machine parameter, the ARM64 PE, the AArch64 TLS descriptors, and the AArch64 GOT/PLT fixes. Net for the ruling's two commits: −750 lines (toyos-ld −784, the rust-lld wiring +34).

• The toolchain builds with lld = true, which puts rust-lld in every stage's sysroot. Bootstrap names the AArch64 userland's linker rust-lld with rpath = false: bootstrap's -Wl,-rpath is a cc driver's argument.
• The hosted rustc builds with lld = false, and the host stage2 is then reassembled with lld = true (build_hosted_rustc, write_config). Under lld = true, bootstrap's Assemble for the x86_64-unknown-toyos stage-2 compiler ensures LldWrapper, hence llvm::Lld and a cmake LLVM for a ToyOS host (fork compile.rs:2474). Under lld = false alone, Sysroot::run removes the host stage2 on every assemble (compile.rs:1938), and the rust-lld std_config names goes with it. So the hosted build runs with lld = false, and the host-only build then runs once more under lld = true. That run compiles nothing new and reassembles stage2 with rust-lld. It is Link everything that boots with rust-lld, and freeze toyos-ld #532's shape, which the two reconcile on.
  • Rejected: keeping a copy of rust-lld outside stage2 and naming it. Every AArch64 link names rust-lld by name and finds it in the sysroot it is compiled with, and each sysroot is cloned from stage2. A copy elsewhere would fix std_config and leave every userland link without its linker. It would also be a second copy of bootstrap's copy_lld_artifacts, and gcc-ld/ would be left out.
  • The host's default-linker-linux-override is pinned "off" in every config that builds a host compiler (HOST_LINKER_PIN, in write_config and the worktree compiler's config_text). Bootstrap ties that override to lld for x86_64-unknown-linux-gnu: lld = true sets CFG_DEFAULT_LINKER_SELF_CONTAINED_LLD_CC, which rustc_target reads through option_env!. The toggle would rebuild the host rustc on Linux in both the hosted build and the reassembly. "off" is what main's lld = false already gave, so no host rustc changes, and on macOS nothing changes at all. The worktree compiler's recipe moves with it: rebuilt here in 13 s.
  • assert_toolchain_is_honest refuses by name a toolchain with no rust-lld (toolchain::rust_lld). The reassembly asserts it too.
• The kernel and loader drop their AArch64 toyos-ld override.
• The loader takes the kernel as a static PIE at base 0, which rust-lld makes of the target's static-model code with -pie -z notext. PIC codegen is not usable there: its GOT slots hold virtual addresses the MMU-off entry cannot use.
• rust-lld's layout exposed a loader defect. The kernel's stack began at the image's last byte, wherever the linker ended it: lld's …908. On the M4 the first stp x29, x30, [sp, #-16]! took an SP alignment fault (ESR_EL1 0x9A000000, read through QEMU's gdb stub on a hardware breakpoint at firmware's vector). TCG does not check SCTLR_EL1.SA there. The stack now starts on the next page.

Stage 2: the loader on AArch64

• Builds for aarch64-unknown-uefi through rust-lld; reads ROOT through firmware block I/O.
• toyos-bootmap types a leaf by concept: Cache::{Firmware, Memory, Device, Scanout} under a Typing. On x86 that is the MTRRs, unchanged; on AArch64, firmware's write-back ranges, with a part-memory 2 MiB page refused. It encodes both architectures' descriptors, host-tested against the Arm ARM's bit positions. The one MAIR_EL1 is declared beside them.
• A scanout's partial 2 MiB pages are split into 4 KiB leaves where memory is typed by the map.
• The loader jumps to the image's physical entry after cleaning it to the point of coherency.
• AAVMF is QEMU 11.1.0's edk2-stable202408 DEBUG build, pinned by hash in NOTICE and src/licence.rs. It carries OpenSSL 3.0.9 (Apache-2.0), now recorded: QEMU builds it with NETWORK_TLS_ENABLE, and ArmVirtQemu links the bundled OpenSSL either way.
• The five-second boot is firmware's boot-menu timeout, not its DEBUG build. Arch::boot passes -boot menu=on,splash-time=0 for AArch64 on both launch paths (see Measured).

TLS, in each machine's variant

The kernel built x86-64's variant II for every thread; the AArch64 std reads its DTV at TP+0, and rust-lld resolves an AArch64 executable's own local-exec accesses to align_up(16, p_align) above TP. toyos_elf::tls now lays out either variant from a Static whose alignments are powers of two by construction, with tpoff per variant. The kernel takes the variant from its ELF machine, places the executable first in variant I and last in variant II, and writes each TCB: [self, DTV] or [DTV, reserved]. x86-64's arithmetic is unchanged.

Stage 3: the kernel on virt

• kernel/src/arch/aarch64/:
  • the entry: at EL2, HCR_EL2 first, an ISB, and a read-back that halts in refused_hcr_el2_readback on any difference from the declaration, before any EL1 register is written; then the drop. E2H held set is one such difference, since the declaration has it clear, and the loader refuses that case by name first, where the console still prints. The kernel's separate E2H branch is deleted. At EL1, MMU off-then-on. The declaration's read-back asserts EL1 on SP_EL1;
  • the control-register declaration, written from constants, read back and asserted;
  • the vectors: every exception reports its class, ELR, FAR, the registers and a backtrace, then panics;
  • the PL011 found through SPCR, barriers, cache maintenance, RNDR.
• toyos-acpi decodes SPCR, GTDT and the MADT's GIC structures, as far as stage 3 reads them.
• The halt every fatal path funnels into is generic (panic::halt_all_cpus).
• The AArch64 kernel builds with -Adead_code -Aunfulfilled_lint_expectations until stage 7 (issues/kernel/the-aarch64-kernel-builds-with-dead-code-allowed.md).

The harness

Profile::Virt is QEMU virt: GICv3, AAVMF, ramfb, the stick on xHCI, the PL011. Profile::VirtEl2 is the same machine with virtualization=on under TCG -cpu max, where AAVMF hands the loader the CPU at EL2. Profile::arch names every variant, with no wildcard. Three tests are in Tier::Local, because no hosted runner boots AArch64 yet (stage 8), and each waits on its last asserted line with drain_until:

• virt_early_panic: the loader's CPU: entered at EL1, the boot log on the PL011, and the panic on both channels in its fatal colours;
• virt_early_fault: an undefined instruction, reported by the vectors;
• virt_el2_drop: the loader's CPU: entered at EL2, HCR_EL2.E2H …, ID_AA64MMFR4_EL1.E2H0 0x0, HCR_EL2 read back as declared, dropped, and the early panic after it.

The entry's EL2 writes of CNTHCTL_EL2, CNTVOFF_EL2 and CPTR_EL2 can each be deleted and virt_el2_drop stays green, because stage 3 reads no counter and runs no FP. The track now records those three mutations under stage 4, whose tests are the first that can red on them.

Measured

• Boot to EARLY PANIC, AArch64 under HVF with test-early-panic armed, from QEMU's start. Pinned AAVMF, three runs per arm, interleaved in one session:

  	runs (s)	loader's first line
  before (the earlier 5.44 s)	5.70, 5.69, 5.70	5.32–5.33 s
  with -boot menu=on,splash-time=0	0.69, 0.69, 0.70	0.33 s

  virt_early_panic and virt_early_fault now take 2 s each (7 s before).

• The RELEASE AAVMF of the owner's ruling was tried and not adopted. The ruling's premise, that the delay is the DEBUG build's, is refuted, and the RELEASE builds tried do not boot reliably:

  • Debian 13's qemu-efi-aarch64_2025.02-8+deb13u1 (licence checked: BSD-2-Clause-Patent AND Apache-2.0, OpenSSL 3.4.0 and Mbed TLS): never reached the loader in six boots.
  • Debian 12's 2022.11-6+deb12u2: 2 of 5 boots, and those took 5.71 and 6.08 s.

• AArch64 userland: the whole workspace but calc/snake/doom builds and links through rust-lld (cargo run -- --arch aarch64 --build-only EXIT=0). init is an ET_DYN AArch64 PIE whose PT_TLS is 64-aligned and whose only dynamic relocations are RELATIVE.

• The primary's bootstrap config, run once. write_config's exact text for this host (lld = true, the host and six guest targets, toyos-ld for x86_64-unknown-toyos, rust-lld with rpath = false for aarch64-unknown-toyos), with one line added, build-dir pointing at the worktree fork checkout's build/toyos-compiler, run as ./x build --stage 2 --warnings warn on the fork at c3cb792df3f: EXIT=0 in 4 min 6 s. It built stage1 std for all seven targets and uplifted each to stage 2, and rust-lld is in the stage 2 sysroot. With that stage2, a std hello-world links for aarch64-unknown-toyos (rust-lld, a static PIE) and for x86_64-unknown-toyos (toyos-ld), EXIT=0 each. What it does not exercise: a fresh build directory (it reused the keyed compiler's, 14 GB, which grew to 15 GB), and the primary's own build/, which holds lld = false artifacts. A fresh one needs more than the 21 to 29 GB this disk had free during the session; the primary's own build/aarch64-apple-darwin is 47 GB.

• The hosted-rustc sequence, from a fresh clone (nightly run 36266825579 at d8bee311; each job runs full_bootstrap, then the hosted rustc, then the reassembly, then the sysroot). Bootstrap's own Build completed times:

  job	host toolchain	hosted rustc (lld = false)	reassembly (lld = true)	sysroot std
  portability-linux (debian sid)	36:54	22:10	0:05	9:39
  portability-macos	38:46	21:47	0:28	7:38
  build (--ci toolchain, ubuntu)	26:59	16:13	0:04	6:34

  The reassembly compiled no crate on either host, which is what the Linux pin is for.

• One compiler of a worktree's own costs 583 MB at rust/build/compilers/<key>/ and 15 GB of incremental build in the worktree's fork checkout (build/toyos-compiler). Its key takes 1.3 to 2.1 s to compute on this fork, 0.6 s of it src/tools.

• Mmio on x86, the x86 kernel built at 3f3ae53e^ and at 3f3ae53e with one toolchain: .text is 0x1c4000 both times; the text symbols sum to 1,753,507 and 1,753,519 bytes (+12) and the disassembly has 471,322 and 471,377 instructions (+55, +0.012%). The commit also moved NVMe's and xHCI's reads, so +55 is an upper bound on what the compiler barriers cost.

• virt's MPIDRs: with 17 CPUs (TCG, -cpu max, GICv3) the MADT names CPU 16 mpidr=0x100, which hardware_id() & 63 puts on slot 0.

Merging main (#530, #528)

origin/main moved to fd62f567 during this round and is merged (a1a143f8). Seven conflicts, each resolved to carry both sides:

• bootloader/src/main.rs: the boot map's ROOT_* names, with Self-update, stage 1: signed A/B slots, ssh … update < image, swap over exec #530's update imports.
• src/image.rs: main's slotted disk, with arch threaded into create_boot_image and create_esp_volume for the removable loader's path.
• src/build.rs: main's Parts, shipped_parts and signing, keyed per architecture. loader_key takes the arch, the embedded key and the floor scope; root_image_key takes the plan and the key; build() writes image_for(plan.arch).
• tests/common/qemu.rs: a test's own firmware variables file where it names one, and otherwise the architecture's pflash.
• toyos-window moves to 0.19.0, past main's 0.18.0, and all three lockfiles that pin it follow, including Existing Rust GUI apps on ToyOS: iced on one winit backend, paced redraws, forks on one branch per base #528's tests/iced-counter.
• tests/common/update.rs names the x86-64 plan and image.

The AArch64 loader reads the slotted layout: virt_ passes on the merge.

Gates, each with its exit code

At 235c5a5b, the merge plus the iced-counter lock. The head, 8c5be843, adds only issue files.

• cargo run -- --ci host: 45 steps, all green, EXIT=0. The whole output was read; its FAILED lines are the loom controls' expected reds and the worktree tests' planted refusals.
• cargo run -- --ci abi-split: EXIT=0 (toyos-window 0.18.0 -> 0.19.0). The first run, before the iced-counter lock followed, was EXIT=1 and named that lockfile.
• cargo test -- virt_: 3 passed, EXIT=0 (at a1a143f8, whose tree differs only in that lockfile). Before the merge it also passed after the last mutation below was restored.
• cargo test --manifest-path kernel-loom/Cargo.toml: 56 passed, EXIT=0
• cargo run -- --build-only and cargo run -- --arch aarch64 --build-only: EXIT=0 each (at a1a143f8)
• The x86 fast tier, cargo test: 397 passed, 4 failed, 6 quarantined and green, EXIT=1. --known-red answers NO for each. The host was loaded throughout by another worktree's spinner at 397% CPU, with a load average of 20 to 28.
  • metal_job_reboot: green alone, and red on main in this PR's earlier A/B (below).
  • lan_mdns_answer: main's SUN_LEN red.
  • quiesce_stops_the_machine: stayed up for 266 s and was green alone. This is issues/kernel/quiesce-stops-the-machine-stayed-up-beside-other-guests.md; the recurrence is appended there.
  • sched_check_build: 85 samples where its p90 needs 100, green alone. Its quarantine row covers another signature, and this one is appended to that row's issue.
• Before the merge, at 8846c021, the fast tier gave 400 passed, 2 failed, EXIT=1: lan_mdns_answer, and quiesce_wakes_on_the_last_exit (green alone; appended to its issue).
• The nightly, before the merge, at d8bee311 (https://github.com/ToyOSOrg/ToyOS/actions/runs/36266825579):
  • portability-linux success, portability-macos success, build success, host success.
  • portability-windows failed, as on main: it is the declared continue-on-error frontier.
  • Every guest, tcg and audio lane is red on nothing left in $TMPDIR: … toyos-toolchain.tar.zst. That is main's: the step comes from Every test's scratch goes with it, and a killed run's with the next #529 and release::install from before it, and main has had no nightly since Every test's scratch goes with it, and a killed run's with the next #529. Filed as issues/build/a-guest-lane-leaves-the-toolchain-tarball-in-its-tmpdir.md.
  • The lanes' suite reds: screen_diag_boot, home_budget_refusal_retried, metal_job_reboot, usb_transport_break and log_flush_retry are each red on main's last nightly too (run 36228604597). fpu_isolation is not: it passed there. Checked out at main's 17eb66a4 in this worktree, with the fork at main's pin, it is red the same way (thread_join answers NotFound), so it is main's. Filed as issues/kernel/fpu-isolation-s-thread-join-answers-not-found-on-main.md.
• The nightly at the head 8c5be843 (https://github.com/ToyOSOrg/ToyOS/actions/runs/36273557690): portability-linux success, portability-macos success, build success, host success. The hosted-rustc reassembly took 0:05 on Linux, 0:25 on macOS and 0:07 in build. Seven guest, tcg and audio lanes had finished at hand-back, and every one was red on the $TMPDIR tarball above. Their suite reds were home_budget_refusal_retried and fpu_isolation, both main's as above, plus two tests Storage stage 3, steps 1–4: toyos-blockring, SYS_DEVICE_DMA_MAP, blockd and partition sessions #525 added after main's last nightly, which no main nightly has run: blockd_survives_its_death and partition_claim_departure. Those two were not A/B'd, and I do not know whose they are.

The two reds of the earlier fast tier (fef790a6), by a same-session A/B. Main at 17eb66a4 in a scratch worktree (/Users/jan/Dev/jan/toyos-arm64-ab) and the branch at da1df5f0, five rounds, each round running both tests on both arms at once. Counts are of each run's own exit code; a run whose harness panicked before any guest booted, on issues/build/two-suites-in-one-worktree-race-on-the-c-corpus-libc.md's race, carries no verdict.

test	main	branch
metal_job_reboot	3 green, 1 red (QEMU died before ===READY===), 1 no verdict	5 green
lan_mdns_answer	4 red (path must be shorter than SUN_LEN), 1 no verdict	5 red, the same line

• metal_job_reboot's fast-tier red was the job drain carried no kernel output at all (24 bytes), then ALONE ... GREEN; the earlier A/B at d65446cc saw that signature on main twice in five.
• lan_mdns_answer is issues/build/a-lane-s-tap-socket-path-is-past-sun-len-on-the-dev-host.md, which Where everything lives: the layout as ruled, and its first stage #531 filed; this branch's duplicate of it is deleted.

The two checks

Negative controls, each applied as a patch, shown to build, run, and restored:

control	test	EXIT
try_lock built with then_some (feature serial-try-lock-then-some, in CONTROLS)	kernel-loom --test serial_lock, both models	101
msr hcr_el2 deleted	virt_el2_drop (the boot halts silently)	1
SPSR_EL2_TO_EL1 = 0x3C4	virt_el2_drop (running at EL1 on SP_EL0)	1
HCR_EL2 declared with E2H, rerun with the kernel's E2H branch deleted	virt_el2_drop (boot timed out before EARLY PANIC)	1
the loader's E2H0 test inverted (e2h0 == 0 refuses)	virt_el2_drop: the loader prints …: REFUSED, HCR_EL2.E2H is RES1 … on the console and stops	1
the loader commit reverted whole, its test lines kept	virt_el2_drop ("CPU: entered at EL2, HCR_EL2.E2H " not on the PL011)	1
the hosted-rustc fix reverted whole: this branch at 446447ca	nightly run 36263298060: portability-macos, portability-linux and build each fail building LLVM for x86_64-unknown-toyos, reached from Assemble → LldWrapper → llvm::Lld, then the hosted rustc build failed. On macOS cmake's compiler check fails (ld: unknown file type); on Linux, Building LLVM for x86_64-unknown-toyos finds no ninja	failure
assert_toolchain_is_honest's rust-lld refusal deleted	toolchain::tests::a_toolchain_bin_without_cargo_is_one_rustup_narrates	101
the arch rules' glob and rename cases reverted whole (17f930eb's function hunks), the fixtures kept	sourcegate::tests::a_pure_crate_that_names_an_architecture_is_red	101
for_executable's TLSDESC refusal deleted	toyos-elf --test tables (an_executable_s_reservation_is_had_only_through_its_refusals)	101
the sweep after a placement deleted	compiler::tests (placing a compiler left the one it replaced)	101
the loader's stack not page-rounded (the whole fix, with its PAGE)	virt_early_panic under HVF: silent after the handoff, the image ending at …039	1
AArch64 mapped to TLS variant II	toyos-elf --test tls	101
the library's R_AARCH64_TLSDESC refusal (rela::validate) deleted	toyos-elf --test tables	101
the arch rules matching core::arch:: as a substring, as before	sourcegate fixture tests, both	101
sweep without its keyed_idle guard	compiler::tests	101
a missing primary record read as empty	compiler::tests	101
copy_backward's chunk test reading 8, not 16	toyos-libc-copies	101

Earlier on this branch, and unchanged: every worktree given the primary's compiler, and a worktree's compiler placed beside the primary's stage2 (compiler::tests, EXIT=101 each); the seqlock writer's fence removed (panic_console_publish, EXIT=101); VBAR_EL1 0x800 off (virt_early_fault, EXIT=1).

Independent oracles:

• rust-lld's own output for variant I: an aarch64-unknown-toyos executable with a 64-aligned PT_TLS addresses .tdata offsets 0 and 0x40 at TP+0x40 and TP+0x80 (add x0, x8, #0x40 / #0x80), which variant_i_agrees_with_what_lld_linked asserts.
• QEMU TCG's EL2 (virtualization=on) and AAVMF, for the drop.
• The M4's own CPU under HVF, which caught the SCTLR_EL1 RES1 bits and the stack alignment TCG let pass, and reds the unrounded-stack control.
• loom, for the serial lock and the seqlock.
• Rust's own copy_within, fill and sqrt, for libc's module on the host.
• QEMU virt and edk2's ArmVirtQemu; the Arm ARM, for every barrier and descriptor bit.
• For the hosted-rustc build, the GitHub-hosted nightly from a fresh clone on both hosts (portability-linux, portability-macos), and the fork's bootstrap source (compile.rs:1938, :2474; config.rs's default_linux_linker_overrides) for why each config line is there.

What I am unsure of

• The loader's E2H0 refusal is shown only by its inverted control: no QEMU CPU model lacks FEAT_E2H0, so the refusing arm has not run on a CPU that needs it. ID_AA64MMFR4_EL1 is read by its encoding on the Arm ARM's word that the ID space reads as zero where a register is not implemented.
• The reassembly relies on nothing linking for AArch64 during the hosted build, while the host stage2 has no rust-lld: the guest std it would link is already built by then. The nightly is the evidence, not a test of that premise.
• The kernel's variant I layout is exercised by no AArch64 process until userland runs on AArch64; the arithmetic is host-tested against lld's output, and the kernel's use of it is by reading.
• --arch aarch64 --build-only has run only with this worktree's keyed compiler. The nightly's fresh-clone jobs build the x86 image; their sysroot step builds the AArch64 std too, with the rust-lld std_config names in the reassembled stage2, but no AArch64 userland links there.
• No lock-order test: the order is compiler key, then sysroot key, then worktree, and a test would have to run a compiler resolve and a sysroot build in one process against fakes of both; not written.
• PAR_EL1's inner nibble: boot_map_write_combining accepts 0b0000 as well as 0b0100, because HVF reports 0x40.
• src/CLAUDE.md still says a fork commit with another compiler/ is refused; the orchestrator owns that file.

What #532 adopts when it reconciles write_config and std_config

Both branches build the hosted rustc under lld = false and then rerun the host-only build under lld = true. What #532 does not have, and must take from here:

1. HOST_LINKER_PIN in write_config and compiler::config_text: [target.<host>] with default-linker-linux-override = "off". Without it, Link everything that boots with rust-lld, and freeze toyos-ld #532's lld = !with_hosted_rustc flips CFG_DEFAULT_LINKER_SELF_CONTAINED_LLD_CC for an x86_64-unknown-linux-gnu host between the two builds. rustc_target reads it through option_env!, so the host rustc is rebuilt in both on Linux, and Linux host rustc's own default linker changes from main's.
2. std_config(compiler, …): it takes the stage2 of the Compiler a worktree resolved (src/compiler.rs), not toolchain::stage2(rust_dir), and names toolchain::rust_lld(compiler) by path. A worktree whose fork has its own compiler/ builds its std with its own compiler's linker. Per architecture it loops over Arch::ALL, and links_through_toyos_ld() chooses the linker: toyos-ld for x86-64 here. Link everything that boots with rust-lld, and freeze toyos-ld #532's x86 switch makes that false for both, and the toyos_ld parameter goes.
3. write_config's guest targets: Arch::ALL, with linker = "rust-lld" and rpath = false for each target that does not link through toyos-ld. Link everything that boots with rust-lld, and freeze toyos-ld #532's hosted build names ci-llvm/bin/lld by path for x86_64-unknown-toyos, because the hosted build's sysroots carry no rust-lld. That stays Link everything that boots with rust-lld, and freeze toyos-ld #532's for x86. AArch64 keeps rust-lld by name, since it links nothing during the hosted build.
4. rust_lld() and the rust-lld refusal in assert_toolchain_is_honest are Link everything that boots with rust-lld, and freeze toyos-ld #532's own shape and names (here pub(crate)); the refusal test is the same.
5. compiler::RECIPE moved to …, host linker pinned; 3. sysroot::RECIPE is untouched here. Link everything that boots with rust-lld, and freeze toyos-ld #532 moves it to …, linked by rust-lld; 3, which is right for the merge.

Filed

• issues/kernel/the-saved-kernel-context-names-x86-registers.md (stage 4)
• issues/kernel/msi-and-pin-routing-take-an-x86-vector-and-apic-id.md (stage 4)
• issues/kernel/the-boot-timing-handoff-is-named-for-the-tsc.md (stage 4)
• issues/kernel/the-crash-evidence-records-x86-fault-registers.md (stage 5)
• issues/kernel/the-aarch64-kernel-builds-with-dead-code-allowed.md (stage 7)
• issues/build/the-primary-rebuilds-its-compiler-on-compiler-alone.md
• issues/build/the-toolkit-forks-resolve-an-x86-only-toyos-window.md
• issues/build/ovmf-s-licence-record-names-no-openssl.md
• issues/build/a-defect-only-contention-exposes-is-classified-as-a-wrong-sched.md
• issues/build/issue-files-cite-paths-that-moved.md: citations that name paths this branch moved; whether a gate belongs is the owner's, since src/CLAUDE.md says documentation carries no gates.
• issues/build/two-suites-in-one-worktree-race-on-the-c-corpus-libc.md
• issues/kernel/fpu-isolation-s-thread-join-answers-not-found-on-main.md (main's, measured at 17eb66a4)
• issues/build/a-guest-lane-leaves-the-toolchain-tarball-in-its-tmpdir.md (main's)
• Appended: the quiesce recurrence to issues/kernel/quiesce-dump-holds-the-stopped-reds-wide-with-usb-transport-breaks.md, the part-typed 2 MiB page to the boot-map issue, the port's stages to issues/kernel/toyos-runs-on-arm64.md, with the three EL2-write mutations stage 4 is the first to red, and the loaded recurrences of quiesce_wakes_on_the_last_exit, quiesce_stops_the_machine and sched_check_build to their issues. issues/build/the-primary-rebuilds-its-compiler-on-compiler-alone.md is assigned to the ARM64 track, closed before its stage 4 lands.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK

[Japabu]

Hand-back for round 2, at head 8c5be843.

BLOCKER 1, the hosted-rustc build. The hosted build now runs with lld = false. build_hosted_rustc then reruns the host-only build with lld = true, which reassembles stage2 with rust-lld and compiles nothing. The host's default-linker-linux-override is pinned "off" in every host-compiler config. Without the pin, bootstrap ties it to lld on x86_64-unknown-linux-gnu, and the toggle would rebuild the host rustc twice. assert_toolchain_is_honest refuses a toolchain with no rust-lld, by name. The rejected alternative and what #532 must adopt are in the body.

• Negative control, this branch at 446447ca (run 36263298060): portability-linux, portability-macos and build each fail building LLVM for x86_64-unknown-toyos, reached from Assemble → LldWrapper.
• The nightly at 8c5be843 (https://github.com/ToyOSOrg/ToyOS/actions/runs/36273557690):
  • portability-linux success, portability-macos success;
  • build success, host success;
  • the reassembly took 0:05, 0:25 and 0:07.
• Also green before the merge, at d8bee311 (run 36266825579).

BLOCKER 2, the arch rules. A glob of core/std, or a rename of either in an import, is refused outright outside arch modules. That covers use core::*, core::{*}, use core as k, extern crate core as k, core::{self as k} and use {…, std as k}. The reviewer's plants are fixtures, and two non-imports stay green. Reverting the function hunks while keeping the fixtures gives EXIT=101.

NOTEs.

• The loader refuses E2H RES1 at EL2 by name, and the kernel's E2H branch is deleted. Inverting the loader's check gives EXIT=1 with the refusal printed. Reverting the loader commit gives EXIT=1. HCR_EL2 declared with E2H gives EXIT=1.
• The three EL2 writes are recorded under stage 4 of the track.
• TLSDESC is refused on its count through RelaCounts::for_executable, the only way to the reservation. The Vec is gone. Deleting the refusal gives EXIT=101.
• Static::variant is deleted.
• The compiler-key issue is assigned to the ARM64 track.
• The compiler sweep runs after every placement. Deleting it gives EXIT=101.
• The rust-lld refusal deleted gives EXIT=101.

Merge. origin/main moved to fd62f567 (#530, #528) and is merged at a1a143f8. Seven conflicts were resolved; toyos-window is 0.19.0.

Gates. At 235c5a5b; the head adds only issues.

• --ci host: 45 steps, EXIT=0, output read whole.
• --ci abi-split: EXIT=0.
• kernel-loom: 56 passed, EXIT=0.
• virt_: 3 passed, EXIT=0.
• --build-only: x86 EXIT=0, aarch64 EXIT=0.
• Fast tier: 397 passed, 4 failed, EXIT=1, under another worktree's load (load average 20 to 28). Each red was green alone or is main's.

Filed. Main's defects the nightly exposed:

• fpu_isolation's thread_join answers NotFound. It is red at main's 17eb66a4, measured by checking that base out here.
• Every guest lane reds on the toolchain tarball left in $TMPDIR.

[Japabu]

Round-2 BLOCKERs closed and judged at 8c5be84: the hosted-rustc build runs with lld off and a host-only lld pass restores rust-lld (nightly 36273557690: portability-linux, portability-macos, build and host green; the negative control is 446447c's run 36263298060, red on all three trying to build LLVM for ToyOS); the arch rules refuse any glob or rename of core/std outside arch modules (revert EXIT=101). The guest lanes' reds trace to main (#529's TMPDIR check vs the toolchain tarball, fpu_isolation red at main's own base) and are filed. src/ and kernel/ CLAUDE.md updated by the orchestrator at 50a1939. Landing.