I have attached below a list of bugs and frustrating things encountered which seem to me plausibly worth up-streaming or might save someone the same many hour headaches. (see attached md files for readability). ---- # Upstream candidates from SpectrumOS work (for Alyssa / Spectrum contacts) (I would love some feedback about which and how to upstream/who to do it) Colby Thomson Collected 2026-07-05 → 07-07 on: Mac Studio M2 (Asahi Fedora 44, kernel 7.0.13-400.asahi.fc44.aarch64+16k), Spectrum-derived guest (16K kernel 7.1.1), qemu 10.x host-side, cosmic-comp 1.0.16, cloud-hypervisor v52. Status flags: [needs-research] = have not yet checked trackers/lists for prior reports; [have-repro] = can produce a reproducer on request. ## 1. arm64 KVM: kcompactd vs nested-virt stage-2 unmap WARN + guest stalls **Target: kvmarm / Asahi Linux.** [known: https://bugzilla.redhat.com/show_bug.cgi?id=2486976] [have-repro] Findings: CVE-2026-46317 covers `kvm_unmap_gfn_range -> kvm_nested_s2_unmap` from the MMU notifier path; fixed per CVE refs in 7.0.12 and 7.1. VERIFIED 2026-07-07 (fable): the fix has NOT reached the Asahi branch — asahi copr's newest kernel is exactly our affected 7.0.13-400 (stock Fedora 7.1.3 has the fix but cannot drive Apple-silicon hosts). ACTIONABLE ASK: backport into the Asahi kernel branch; we supply fresh repro data from 7.0.13-400+16k and the working mitigation (compaction_proactiveness=0). Searched lore kvmarm/linux-mm, Asahi GitHub, linux.git/stable log, 2026-07-07; direct lore advisory fetch returned 403. `WARNING arch/arm64/kvm/mmu.c:336 __unmap_stage2_range` fired from `kcompactd0` via `kvm_mmu_notifier_invalidate_range_start -> kvm_nested_s2_unmap` on 7.0.13-400.asahi +16k while a qemu guest ran with `virtualization=on` (nested KVM for inner cloud-hypervisor VMs). Correlates with hard guest-vCPU stalls: guest-side soft lockups (arbitrary victim threads), boots taking 10-20 min or wedging entirely. Trigger condition is host memory fragmentation (appears after heavy build churn; fresh host is fine). Workaround that eliminates it: `vm.compaction_proactiveness=0` plus manual `compact_memory` before launching guests. Nested virt on arm64 is young — plausibly unknown, and the 16K-page Asahi angle narrows it further. Full dmesg + timeline available. ## 2. cosmic-comp/cosmic-config: hard panic when XDG_CONFIG_HOME is read-only **Target: pop-os/libcosmic (cosmic-config), possibly cosmic-comp.** [likely-new: searched pop-os/libcosmic issues for ReadOnlyFilesystem/read-only/config panic and pop-os/cosmic-comp issues for ReadOnlyFilesystem/shortcuts/XDG_CONFIG_HOME, 2026-07-07] [have-repro] Findings: No exact read-only panic found. Closest missing-defaults/no-XDG-data-fallback issue: https://github.com/pop-os/cosmic-comp/issues/2309 Older related config-read failure: https://github.com/pop-os/cosmic-comp/issues/917. cosmic-config writes defaults for missing entries at load; on a read-only config dir cosmic-comp panics at startup ("Failed to load shortcuts config: … ReadOnlyFilesystem", src/config/mod.rs). Any immutable-rootfs deployment (Spectrum-style, kiosks, live media) hits this. Suggested upstream behavior: fall back to in-memory defaults instead of panicking. Our workaround: seed a writable copy in /run at service start. re-verified against cosmic 1.2.0 tonight — still unfixed upstream ## 3. qemu (aarch64 host): GTK display with gl=on wedges and ignores SIGTERM **Target: qemu.** [likely-new: searched qemu-project GitLab issues for GTK/gl=on/aarch64/SIGTERM wedge and Asahi Linux GitHub issues for qemu/gl=on/Honeykrisp/Mesa, 2026-07-07] Findings: No exact aarch64/Asahi wedge found. Related generic GTK GL issues: https://gitlab.com/qemu-project/qemu/-/issues/3954 https://gitlab.com/qemu-project/qemu/-/issues/2387 qemu-system-aarch64 with the GTK UI + gl=on on Asahi (Mesa/Honeykrisp) reliably becomes "not responding", ignores SIGTERM (needs SIGKILL), and keeps the disk-image write lock while dead. Software/VNC display is fine. May be a known Mesa-on-Asahi interaction ## 4. KRDC: VNC pixel-format misrender (solid blue) against qemu VNC server **Target: KDE krdc.** [known: https://bugs.kde.org/show_bug.cgi?id=247149] [have-repro] Findings: KDE bug 247149 is qemu/Xvnc VNC wrong colors from bad pixel-format shifts. Resolved fixed by SVN r1186718 for the KDE 4.5 branch in 2010. Current solid-blue behavior is probably a regression or a new pixel-format/endianness variant. KRDC renders qemu's VNC framebuffer as a solid blue field (pixel format / endianness handling); TigerVNC renders the same server correctly. Trivial to reproduce with any qemu VNC display on aarch64. ## 5. cloud-hypervisor/crosvm: vhost-user shmem map compatibility **Target: cloud-hypervisor (maybe crosvm).** [known: https://inbox.spectrum-os.org/spectrum-devel/20260626185509.3715326-10-colby%40colbyt.com/T/] Findings: Spectrum carries `0003-vhost_user-add-crosvm-shmem-map-compat.patch` for crosvm SHMEM_MAP compatibility. No exact Cloud Hypervisor issue/PR found; related GPU idea: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/3212. spectrum-os.org git/cgit was reachable only to an Anubis access-denied page; public inbox was reachable. We carry `0003-vhost_user-add-crosvm-shmem-map-compat.patch` in spectrum/pkgs/cloud-hypervisor — interop between cloud-hypervisor's vhost-user backend and crosvm-style shmem mapping requests. ## 6. For Spectrum itself (not upstream-upstream, but Alyssa's tree) - **16K-page guest kernel config** for Apple-Silicon KVM hosts (M-series hosts run 16K pages; a 4K Spectrum guest kernel can't boot under KVM there). We maintain a working 16K kernel config + build wiring; happy to share. Also validated the same guest on NVIDIA GB10 (4K host / 16K guest). - **s6 readiness for cosmic-comp sessions**: the weston-style readiness pipe (piperw + notification fd) never fires with cosmic-comp 1.0.16 — services depending on compositor readiness deadlock the s6-rc transition. RESOLVED as OUR bug (2026-07-07): our wayland-socket patch never ported weston's ready-byte write — the byte cannot fire by construction. Fix is ~5 lines in our patch (write fd-3 byte after socket bind), planned with the cosmic-comp 1.2.0 bump. NOT an upstream item. Spectrum-relevant only as a heads-up if they adopt COSMIC with the weston-style readiness pipe. ## MACOS (resolved upstream) ## 7. qemu: HVF backend asserts on macOS 26.5 (SME register renumbering) **Target: qemu (hvf/arm).** [needs-research] [have-repro] qemu-system-aarch64 from current nixpkgs aborts at vcpu init under macOS 26.5 Hypervisor.framework: assertion at target/arm/hvf/sysreg.c.inc:149, `HV_SYS_REG_SMCR_EL1 == KVMID_TO_HVF(...)` — Apple renumbered/extended the HVF sysreg IDs (SME) in the macOS 26 SDK. Reproduces identically on two M3 Ultra machines (26.5.2) with nixpkgs darwin.linux-builder. RESOLVED for us 2026-07-07: nixpkgs-unstable's qemu boots the same VM fine on both Macs — so the fix exists upstream already and this is a nixpkgs STABLE-CHANNEL BACKPORT ask (pin: darwin.linux-builder on the stable channel is broken onmacOS 26.x until the newer qemu lands there).