Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

virtio-gpu takeover: what was wrong, what is fixed, what is left

Aperta
  • Qualcosa non va?
#254 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
c
Ambito
operating-systems

Direzione di ricerca

Start with the stated open work: nextbsd-kernel-extensions/.github/workflows/build.yml:41, the arm64 CI workflow, and issue #170. Reproduce the documented path with an arm64 QEMU or UTM guest using dmesg | grep -E "vtgpu|VT:"; completion depends on which follow-up is selected, such as correcting the branch label, adding the manual CI lane, or designing virtio_gpu parent-child coexistence.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

State as of 2026-09-25, so none of it has to be rediscovered.

Fixed and merged

nextbsd-kernel#252 — reverted nodevice virtio_gpu and fixed the fault it was avoiding.

Verified on arm64 qemu with a GPU:

VT: init without driver.
vtgpu0: <VirtIO GPU> on virtio_pci0
VT: initialize with new VT driver "virtio_gpu".        <- early console restored
VT: Switching back from "virtio_gpu" to "virtio_gpu".  <- vt_deallocate, printf unchanged
vtgpu0: detached
virtio_gpu_drm0: <VirtIO GPU (DRM/KMS)> on virtio_pci0
[drm] Initialized virtio_gpu 0.1.0 for virtio_pci0 on minor 0
VT: initialize with new VT driver "drmfb"              <- patch 0058 working

initialize rather than Replacing is the proof: vt(4) dropped to no backend, so the framebuffer free() had nothing pointing at it. Zero panics.

What the root cause actually was

Not a regression in our code. The three defects are stock FreeBSD, introduced by 76e2f976561f, 2015-03-01, and byte-identical on releng/15.0, releng/15.1, stable/15 and main:

  1. vt_allocate() assigns vd_driver = drv before vt_replace_backend() reads it, so on the first-ever backend the driver becomes its own predecessor (vd_prev_driver == drv, vd_prev_softc == NULL).
  2. vt_deallocate()'s guard passes on that, prints Switching back from X to X, then vt_replace_backend(NULL,NULL)'s downgrade arm requires vd_prev_softc != NULL — so neither arm runs, vt keeps a dangling backend, and the flush timer is re-armed.
  3. vtgpu_detach() ignores the return and free()s the contigmalloc'd framebuffer, unmapping its KVA.

It is a race, not a certainty — you fault only if a flush lands before the new backend installs. The 20260921 image demonstrably won that race.

What made an 11-year-old latent bug reachable: nextbsd-userland 64422f0 (2026-09-01) — "arm64 has never run its own kexts". Until then unsuffixed x86-64 kext tarballs overwrote the arm64 ones and every kext failed with Exec format error, so the takeover could not execute at all.

Ruled out with evidence, so nobody repeats it: freebsd-src (moved p2→p3 on 08-26, but vt_core.c blob identical and the delta is 15 errata commits with zero overlap); the drm-kmod pin (moved back 219 commits, but vt_drmfb.c unchanged since 2026-02-21 and the branch was frozen 06-14→09-07); the NextBSD patch series (no patch touches sys/dev/vt/**, ever); the Pi 500+ work (bcm2835_fbd, unreachable from qemu virt).

Deliberately NOT fixed

vt_allocate()'s self-referential vd_prev_driver. Correcting it makes vt_deallocate() return EPERM for a sole backend, the detach fails, and the kext leaves base in place with no KMS — a race that usually wins becomes a guaranteed loss. That seeding is what lets the handover happen; patches/0058 makes it safe rather than preventing it.

Still open

  • nextbsd-kernel-extensions#85 — a manual, test-only CI lane (build.yml minus publish).
  • #170 — the coexistence design: base publishes a virtio_gpu_drm child (the vga_pci→drmn shape upstream prescribed when retiring DF_REBID), so drmfb outranks base at the vt priority ladder and nothing detaches at all. Not needed now that the handover is safe; it is the cleaner end state. Open problem: virtqueue ownership between parent and child.
  • The three vt(4)/vtgpu defects are upstreamable to FreeBSD as-is — reproducible on stock releng/15.1 with devctl detach vtgpu0 on any arm64 guest whose only vt backend is virtio-gpu.
  • drm_v6.12.110 — needs four sites in graphics/drivers/gpu/drm/drm_fbdev_shmem.c adapted first (upstream 75dc0eaf74 unexported drm_fb_helper_alloc_info/release_info).
  • The unsuffixed, amd64 graphics-kexts.tar.gz is still laid into amd64 images.
  • FREEBSD_BRANCH: releng/15.1 is an unpinned branch cloned --depth 1 on a weekly cron, so errata reach CI within 7 days with no commit here.
  • nextbsd-kernel-extensions/.github/workflows/build.yml:41 still says FREEBSD_BRANCH: releng/15.0. It is inert — used only in a release note — but it labels every kext release as built against 15.0 when the toolchain supplies 15.1.

Why CI never caught any of this

The arm64 smoke lane had no display device at all, so vtgpu0 never attached and none of this path ran. It also had no serial console (the image mutes boot_mutemsgs), took amd64 kexts over its own, used a gate that disagreed with its own expect block, and exited at login before kextd loaded anything. All fixed in #252; the lane now boots with -device virtio-gpu-pci and asserts the handover.

To carry on

  1. Dispatch nextbsd-pkg (manual by design — it packages base + kernel + userland + contrib + kexts)
  2. Rebuild the ISO (build.sh installs the whole OS from the pkg repo, so it cannot skip step 1)
  3. Boot UTM. The diagnostic is dmesg | grep -E "vtgpu|VT:" — initialize with new VT driver "virtio_gpu" means UTM runs the same path now fixed on qemu. If vtgpu is absent or its attach failed, the takeover fix is still correct but nothing requests the kext there, which is a trigger question and not a fault.
Lingua principale
C
Stelle
12
Fork
3
Merge medio
7h 1m
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextbsd/nextbsd-kernel

Tutte le issue di nextbsd/nextbsd-kernel

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.