Claim: the maintainer's answer on Phase 5 is in the plan. On x86_64 guests reach Glint's devices only through I/O ports, with no instruction decoder; 5.5's virtio-pci uses configuration ports 0xcf8/0xcfc and virtio's legacy I/O-port BAR. On aarch64 the data-abort syndrome gives size and register for single-register loads and stores, so no decoder is needed there. A new Track U (docs/phases/U-usb.md) places USB, Glint's primary peripheral: guests see an emulated xHCI; Glint keeps the real controller. U.1 (register file) after Phase 5; U.2-U.5 (rings, a virtual keyboard, Glint's own xHCI driver, forwarding) after Phase 6 and before Phase 7; U.6 on Beagle hardware with Phase 13. The emulated controller is aarch64-only, since xHCI's registers are only memory-mapped. Open question 2 is answered. Passage: the maintainer, relayed in glint 366ac226de: 'For x86, that sounds like it makes sense... Emulating the USB controller is the primary peripheral to be captured by Glint.' xv6 6, on what a driver does. Demonstration: each fact is cited. QEMU 11.1.2 translate-a64.c sets iss_valid only for LDR/STR without writeback; hcd-xhci-pci.c:165 registers xHCI's BAR 0 as 64-bit memory; virtio-pci.c:2155 the legacy I/O BAR. U-Boot 2026.07: AM62x has snps,dwc3 and J722S cdns,usb3, both calling xhci_register in host mode; xhci-generic.c binds generic-xhci. Linux's generic-xhci binding is marked unverified (no Linux source here). Size: PLAN.md about 35 lines, 05-page-faults.md 5 lines, U-usb.md 100 lines.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KMXZyLk8eDgCjvQ9hX check-in: dd05f46cdb user: x86-1-glint tags: trunk