issues: user programs use AVX under XSAVE is done, and the records stop saying otherwise

issues/ap-control-registers-inherit-init.md

@@ -11,7 +11,7 @@ opened: 2026-08-09
 and `PG` into, so cores 1..N ran with `CD`/`NW` set — caching off — and with
 `WP`, `NE` and `MP` clear. Both registers are now written whole from one
 declaration, applied on every CPU and asserted there, and the `control_regs`
-gate holds every bit of `CR0` and eight of `CR4` against that declaration
+gate holds every bit of `CR0` and `CR4` it names against that declaration
 independently of the kernel's own self-check.
 
 What that leaves is a number nobody has: **how much an uncached AP cost.** It is
@@ -61,13 +61,12 @@ on a host that prices `CD` at zero it would answer the same on both.
 ## What is *not* open, recorded because three places used to say it was
 
 **`CR4.OSXSAVE` diverging between the BSP and the APs** — the hypothesis
-that firmware leaves it set so cpu0 permits AVX and an AP `#UD`s on it,
-killing a thread that migrates. The
-declaration is written whole rather than OR'd, so `write_cr4` clears the bit on
-the BSP as well; it is in neither `CR4_REQUIRED` nor `CR4_OPTIONAL`, the gate
-asserts it clear on every CPU by name, and a second arm refuses any bit the gate
-never named. The divergence is unrepresentable on the T14 as much as here, so
-that hypothesis needs no machine.
+that one CPU permits AVX and another `#UD`s on it, killing a thread that
+migrates. The declaration is written whole rather than OR'd; `OSXSAVE` is in
+`CR4_REQUIRED`, every CPU asserts it set and asserts the `XCR0` the BSP
+declared, the gate checks it set on every CPU by name, and a second arm refuses
+any bit the gate never named. The divergence is unrepresentable on the T14 as
+much as here, so that hypothesis needs no machine.
 
 **Whether `CR0.NE` clear was *the* cause of `fault_gates`' one `0xb881`
 survivor** — an unmasked x87 exception signalled on FERR# instead of raising

issues/toyos-crypto-is-in-the-tree-on-par-with-ring-and-secure.md

@@ -157,8 +157,6 @@ Not consumers:
    - **Exit:**
      - On both benches, every row a consumer uses passes on the ISA each
        build records. That ISA is now AVX-capable state on both benches.
-       `issues/user-programs-use-avx-under-xsave.md`'s remaining exit,
-       userland threads' state, is not a gate here.
      - Parity work reads ring's, BoringSSL's and OpenSSL's perlasm or C only
        through a clean room, as root's research rule says.
      - Faster code is accepted only with stage 4's evidence for it.

issues/toyos-uses-what-modern-hardware-offers-for-speed.md

@@ -79,8 +79,6 @@ The CPU cap is PR #865's (`wt/toyos-cpus`), a design round of its own.
 **Exit**: every issue below is closed. They are listed in the order they are
 taken: the instruments, then what is measured, then the design rounds not
 yet measured.
-`issues/user-programs-use-avx-under-xsave.md` is PR #859's, built ahead of
-that order.
 
 - `issues/no-test-can-hold-a-thread-on-a-named-cpu.md`
 - `issues/no-program-measures-toyos-against-linux-on-one-machine.md`
@@ -89,7 +87,6 @@ that order.
 - `issues/a-wake-storm-costs-the-t14-twice-the-amd-benchs-time-per-waiter-and-nothing-says-why.md`
 - `issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md`
 - `issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md`
-- `issues/user-programs-use-avx-under-xsave.md`
 - `issues/no-gate-decodes-kernel-elfs-instructions.md`
 - `issues/kernel-forward-copies-and-fills-are-one-rep-movsb-or-stosb-on-every-cpu.md`
 - `issues/the-direct-map-uses-1-gib-leaves-where-the-cpu-has-them.md`

issues/user-programs-have-no-protection-keys.md

@@ -10,9 +10,8 @@ opened: 2026-09-29
 part of its own memory off from itself. Linux at `Ubuntu-6.8.0-142.142` builds
 with `X86_INTEL_MEMORY_PROTECTION_KEYS`
 (`debian.master/config/annotations:15334`). Its ABI is approved in principle
-and shaped in this issue's pull request, which lands after
-`issues/user-programs-use-avx-under-xsave.md`, since PKRU is XSAVE
-state.
+and shaped in this issue's pull request. PKRU is XSAVE state, which
+`kernel::xsave::xcr0` does not yet enable.
 
 **Exit**: under TCG with `+pku` (`target/i386/cpu.c:992` at QEMU v11.1.1), on
 the T14, and on each EPYC guest that enumerates PKU: a write under a key the