Upstream candidates and other land mines on the way to cosmic / apple native

Upstream candidates and other land mines on the way to cosmic / apple native

[colby]

[-- Attachment #1.1: Type: text/plain, Size: 7192 bytes --]

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 <colby@colbyt.com>

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).

[-- Attachment #1.2: Type: text/html, Size: 11203 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: upstream-candidates-2026-07-07.md --]
[-- Type: text/markdown; name=upstream-candidates-2026-07-07.md, Size: 6904 bytes --]

# Upstream candidates from SpectrumOS work (for Alyssa / Spectrum contacts)

Colby Thomson <colby@colbyt.com> 

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

## 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 on
macOS 26.x until the newer qemu lands there).