← Back · builds on the in-kernel IOKit matcher, the ko→kext conversion, and the shipped drm-kmod → IntelGraphics/AMDGraphics/RadeonGraphics kexts
NextBSD already builds drm-kmod (Intel/AMD/Radeon) into Apple-style .kext bundles that the in-kernel IOKit matcher autoloads. But that whole match → autoload → bind → KMS path is untested end-to-end — qemu emulates no real Intel/AMD/Radeon GPU, so those drivers can never reach attach in CI. A DRM driver for a virtual GPU fixes both gaps at once: real KMS graphics in VMs, and the first true end-to-end graphics CI test. This plan scopes the open virtual-GPU ports (bochs, virtio-gpu, vmwgfx, VirtualBox vboxvideo), the repo architecture (an unmodified drm-kmod fork + a single nextbsd-graphics kext factory), and the separate, license-constrained NVIDIA legacy track.
Guiding principle Start with bochs. It binds qemu’s default -vga std device (1234:1111) with no qemu reconfiguration, and matches as a raw IOPCIPrimaryMatch PCI node — exactly the personality shape ko2kext.sh already emits for i915/amd/radeon. So it unlocks the first end-to-end CI test by reusing the existing match→kextd→load→bind machinery unchanged. The real cost is not the driver; it is the missing DRM GEM helper(s) that drm-kmod never compiles. virtio-gpu and vmwgfx are larger follow-ons; NVIDIA is a separate, license-shaped repo.
nextbsd-graphicsNextBSD builds the FreeBSD drm-kmod port (branch 6.6-lts) green in CI — the drm.ko/drmn core, ttm.ko, dmabuf.ko, linuxkpi, plus the i915kms/amdgpu/radeonkms drivers — each wrapped into an Apple-style .kext with IOPCIPrimaryMatch personalities so the in-kernel IOKit matcher autoloads the matched driver via kextd. That entire match→autoload→bind→KMS pipeline is, today, untested end-to-end: qemu emulates no real Intel/AMD/Radeon GPU, so those drivers can never device-match in CI. Their personalities are only unit-tested (personalities-selftest.sh); no driver ever reaches attach.
A DRM driver for a virtual GPU changes that on both axes: (a) real KMS graphics inside VMs, and (b) the first true end-to-end CI test, because a virtual-GPU device actually appears on the qemu PCI bus and binds.
The honest catch drm-kmod 6.6-lts vendors none of these drivers. Its drivers/gpu/drm/ holds only amd, display, i915, radeon, scheduler, ttm — no tiny/ (bochs), no virtio, no vmwgfx. (It once shipped vboxvideo + vmwgfx and removed them in commit 787a917 — unmaintained >1yr, drm-kmod issue #356.) So every candidate is a net-new port: vendor the Linux 6.6 source, write a FreeBSD bsd.kmod.mk Makefile, fill the gaps — all on top of the unmodified drm-kmod core.
| Driver | Target device | Where it binds | Missing helper to vendor | Hardest gap | PoC effort | Kext match | CI value |
|---|---|---|---|---|---|---|---|
| bochs | Bochs VBE / stdvga 1234:1111 | qemu -vga std (default) — no config change | drm_gem_vram_helper + drm_simple_kms_helper | TTM-coupled VRAM helper | 1–2 wks | raw 0x11111234 | highest |
| vboxvideo | VBoxVGA 80ee:beef | VirtualBox (set adapter = VBoxVGA) | drm_gem_vram_helper + fbdev-TTM (same VRAM helper as bochs) | shares the bochs VRAM-helper gate | ~days after bochs | raw 0xbeef80ee | medium (needs VirtualBox) |
| virtio-gpu | virtio-gpu 1af4:1050 (virtio type 16) | qemu -device virtio-gpu-pci | drm_gem_shmem_helper | no linuxkpi virtio layer at all | 2–4 wks (revive prior art) | virtio sub-bus (not raw PCI) | high (different match path) |
| vmwgfx | VMware SVGA II 15ad:0405 | qemu -vga vmware / real VMware | brings its own ttm_object.c | page_dirty mmap write-protect over Linux MM | 3–6 wks | raw 0x040515ad | low (real value = VMware guests) |
The cheapest path. A single ~950-LOC file (drivers/gpu/drm/tiny/bochs.c), pure MMIO (Bochs DISPI over a BAR offset, with an 0x1ce/0x1cf I/O-port fallback) — no command FIFO, no hypervisor backdoor, no virtio. It matches qemu’s default -vga std device, so the kext device-matches in CI with no qemu change (the same match covers -device bochs-display). The PCI register/autoload plumbing (linux_pci_register_drm_driver) already exists in drm-kmod’s linuxkpi. The work is the two missing helpers. The canonical failure mode (freebsd/drm-kmod issue #62, “binds but black screen”) is exactly the symptom of getting the TTM-coupled VRAM helper 90% right.
The mainline Linux drivers/gpu/drm/vboxvideo/ driver (a few kLOC; MMIO + the HGSMI guest↔host protocol, no firmware, single PCI id 80ee:beef) is its own small driver — and it needs the same drm_gem_vram_helper bochs forces. So once that helper exists in the shared module (§5), vboxvideo is days of work, not weeks. Note: FreeBSD’s emulators/virtualbox-ose-additions ships only the legacy Xorg vboxvideo_drv.so (UMS) + vboxguest.ko/vboxvfs.ko — no KMS, no /dev/dri, no Wayland — so a modern KMS vboxvideo kext is genuinely net-new value for VirtualBox guests. Caveat: VirtualBox’s newer VBoxSVGA adapter reports the VMware id 15ad:0405 and is driven by vmwgfx, not vboxvideo — so target/standardize on the VBoxVGA adapter for this kext.
The “modern VM” answer (qemu/KVM, crosvm, cloud-hypervisor), with abandoned prior art (Alex Richardson’s port on ravynsoft/drm-kmod branch virtio, orig. freebsd/drm-kmod PR #119 against Linux 5.5). Two blockers: (1) linuxkpi has zero virtio support — no <linux/virtio.h>, virtio_device, virtqueue, virtio_driver; FreeBSD’s native sys/dev/virtio is structurally different (newbus, virtio_alloc_virtqueues, virtqueue_enqueue), so a bridge must be hand-written. The ~208-LOC linux_virtio.c prototype maps the common calls but has compile errors, panic() stubs for the mandatory reset/del_vqs, and is against 5.5. (2) drm_gem_shmem_helper.c backs virtio-gpu’s entire buffer lifecycle and is absent. And it does not match as a raw PCI node — FreeBSD’s virtio_pci claims 1af4:1050 and presents a child keyed by a virtio device-type ivar (GPU = 16), so the IOPCIPrimaryMatch model doesn’t apply and new IOKit-matcher plumbing is needed.
Architecturally friendly (TTM-based, no virtio, slots next to radeon/amdgpu) but large (~45k vendored lines) with genuinely hard linuxkpi gaps concentrated in vmwgfx_page_dirty.c (mmap write-protect / mkwrite dirty-tracking over Linux MM internals that linuxkpi does not expose). The small shims (asm/vmware.h, asm/hypervisor.h, linux/cc_platform.h, kmap_atomic_prot) are cheap; FreeBSD base already ships sys/x86/include/vmware.h. For the CI goal it is poor cost/benefit — bochs reaches the same milestone for a fraction of the code. vmwgfx’s value is real VMware/ESXi/Workstation guest support + 3D, not the CI test (qemu -vga vmware emulates only the 2D-incomplete SVGA2).
The single most important finding: the real cost of every tiny virtual-GPU driver is a DRM GEM-helper layer that drm-kmod never compiles — not the driver .c files. drm-kmod ships ttm/ + drm_gem_ttm_helper, but lacks the convenience helpers these drivers sit on:
| Helper | Needed by | In drm-kmod 6.6-lts? |
|---|---|---|
drm_gem_vram_helper.c (~1050 LOC, TTM-backed VRAM GEM) | bochs, vboxvideo | missing |
drm_simple_kms_helper.c (~550, pure-core) | bochs | missing |
drm_gem_shmem_helper.c (~1000, GPL-2.0) | virtio-gpu | missing |
ttm/, drm_gem_ttm_helper, atomic/format/fbdev helpers | all | present |
This is what makes bochs the right first step: porting drm_gem_vram_helper (the TTM-coupled, make-or-break piece) is most of the bochs effort — and it simultaneously unblocks vboxvideo. virtio-gpu needs a different helper (gem_shmem) and the virtio bridge; vmwgfx brings its own object manager. So the helper work isn’t throwaway: it is the foundation the open-driver track is built on.
P0 — bochs. The only candidate that (1) binds qemu’s default VGA with no reconfiguration, (2) matches as a raw IOPCIPrimaryMatch node — reusing the existing match→kextd→load→bind machinery unchanged, and (3) is small and self-contained. It is the cheapest thing that delivers the first true end-to-end graphics CI test. Substantive work = drm_simple_kms_helper.c (low risk) + drm_gem_vram_helper.c (the blocker).
P0.5 — vboxvideo, folded in right after bochs since it reuses the same VRAM helper. Cheap incremental KMS for VirtualBox guests.
P1 — virtio-gpu, the modern-VM follow-on — eyes open that the virtio KPI bridge is the dominant cost, not the driver. Plus drm_gem_shmem_helper and new sub-bus matcher plumbing. PoC ~2–4 wks given the prototype; production 2–4 months. virgl/3D explicitly out of scope.
P2 — vmwgfx, optional, justified only for real VMware guest support. The page_dirty MM port is the schedule risk; a first cut can stub it (losing the 2D dirty fast path) to get KMS up.
nextbsd-graphicsVersion target — planned bump NextBSD is moving its drm core 6.6 → 6.12. The fork tracks 6.12-lts (the branch exists), the new drivers vendor Linux 6.12 sources, and the kernel-baked linuxkpi becomes LINUXKPI_VERSION 61200. Because drm-612-kmod needs a newer linuxkpi than releng/15.0 bakes, this likely pulls the FreeBSD base to 15.1 / 15-stable — the maintainer accepts that bump. The NVIDIA bridge follows in lockstep: graphics/nvidia-drm-612-kmod (rebuilding the NVIDIA ports against 6.12 as needed). References to 6.6-lts / LINUXKPI_VERSION 60600 elsewhere in this plan describe today’s shipping state — read them as 6.12-lts / 61200 once the bump lands.
Keep the design intact: fork freebsd/drm-kmod UNMODIFIED (a SHA-pinned mirror under nextbsd-redux) and add a single companion repo — nextbsd-graphics — that vendors the extra drivers + Makefiles + helper sources + linuxkpi shims and builds against the fork. This mirrors how nextbsd-kernel-modules layers on the kernel, and keeps the fork a clean, rebaseable upstream mirror.
drm-kmod builds out-of-tree: a top Makefile descends via bsd.subdir.mk into per-module dirs (dmabuf/ttm/drm/amd/radeon/i915), each a self-contained bsd.kmod.mk driven by SYSDIR=/usr/src/sys. A new driver is just another such subdir — a near-copy of i915/Makefile: the verbatim -I block (linuxkpi/gplv2/include, linuxkpi/bsd/include, ${SYSDIR}/compat/linuxkpi/common/include, the fork’s include/include/drm/include/uapi), -DLINUXKPI_VERSION=60600, per-driver -DCONFIG_* and the required string defines (-DKBUILD_MODNAME, -DLINUXKPI_PARAM_PREFIX). MODULE_DEPEND lines live in a glue C file (<driver>_freebsd.c): MODULE_DEPEND(<kmod>, drmn, 2,2,2) + ttm/linuxkpi/dmabuf as needed (linuxkpi is baked into the NextBSD kernel, so no OSBundleLibraries for it).
Key decision Where the missing helpers live. The GEM helpers are drm-core code, and the plan forbids modifying the fork — and if two drivers each bundle the same VRAM helper, EXPORT_SYMS collide. Resolution: a small companion drm_extra_helpers.ko that compiles the missing helpers once, exports them, and that each new driver MODULE_DEPENDs on. This preserves “fork unmodified” without symbol duplication. (drm_gem_shmem_helper.c is GPL-2.0 — fine in the gplv2 companion module, but isolate it.)
Today’s CI does git clone --depth 1 --branch 6.6-lts — not reproducible (the branch moves, and the kernel-baked linuxkpi LINUXKPI_VERSION 60600 must match the fork’s linuxkpi_version.mk or symbols drift). The companion repo MUST pin the fork to a SHA (a git submodule with a locked commit; nesting also makes the relative -I paths resolve naturally). In CI: check out the pinned fork SHA, build it inside make.py … buildenv, then build the companion drivers + drm_extra_helpers.ko against that checkout, linking at load via MODULE_DEPEND. Always rebuild the fork and the extras together from the pinned pair.
Reuse ko2kext.sh and add per-driver personality generators modeled on gen-i915-personalities.sh (each parses its driver’s own PCI id table):
| Driver | Kext | Match |
|---|---|---|
| bochs | BochsGraphics.kext | IOPCIPrimaryMatch 0x11111234 (ideally 4-tuple incl. subsystem 1af4:1100; do not add qxl 1b36:0100) |
| vboxvideo | VBoxGraphics.kext | IOPCIPrimaryMatch 0xbeef80ee (VBoxVGA) |
| virtio-gpu | VirtIOGraphics.kext | virtio sub-bus (device-type ivar 16) — needs new matcher plumbing |
| vmwgfx | VMwareGraphics.kext | IOPCIPrimaryMatch 0x040515ad |
All wrap with ko2kext.sh -l org.nextbsd.kext.iographics (the drm core); no -f firmware — virtual GPUs ship none (a welcome contrast to amdgpu’s hundreds of MB).
The full set across the shipping work and this plan. Bundle ids follow org.nextbsd.kext.<name> (lowercased). ␀ = proposed name (open to change).
| Kext | Wraps (.ko) | GPU / role | Device match | Depends on | Status |
|---|---|---|---|---|---|
| IOGraphics | drm.ko | DRM/KMS core (shared family) | — (loaded as dep) | DMABuf | shipping |
| DMABuf | dmabuf.ko | dma-buf sharing | — | (linuxkpi baked) | shipping |
| TTM | ttm.ko | GPU memory manager | — | IOGraphics | shipping |
| IntelGraphics | i915kms.ko | Intel iGPU | 0x….8086 | IOGraphics, TTM | shipping |
| AMDGraphics | amdgpu.ko | AMD GCN+/RDNA | 0x….1002 | IOGraphics, TTM, DMABuf | shipping |
| RadeonGraphics | radeonkms.ko | older ATI/AMD Radeon | 0x….1002 (de-overlapped vs amdgpu) | IOGraphics, TTM | shipping |
| DRMExtraHelpers ␀ | drm_extra_helpers.ko | gem_vram + gem_shmem + simple_kms helpers | — | IOGraphics, TTM | planned P0 |
| BochsGraphics ␀ | bochsdrm.ko | Bochs / stdvga (qemu default) | 0x11111234 | IOGraphics, TTM, DRMExtraHelpers | planned P0 |
| VBoxGraphics ␀ | vboxvideo.ko | VirtualBox VBoxVGA | 0xbeef80ee | IOGraphics, TTM, DRMExtraHelpers | planned P0.5 |
| VirtIOGraphics ␀ | virtio_gpu.ko | virtio-gpu (qemu/KVM/cloud) | virtio sub-bus (type 16) | IOGraphics, DRMExtraHelpers, virtio | planned P1 |
| VMwareGraphics ␀ | vmwgfx.ko | VMware SVGA II | 0x040515ad | IOGraphics, TTM | planned P2 |
NVIDIA — one kext per FreeBSD nvidia-kmod* port (separate recipe repo; see §7) | |||||
| NVIDIA ␀ | nvidia + nvidia-modeset + nvidia-drm (main) | Turing+ (RTX 20xx→Blackwell) | 0x10de:* (main list) | IOGraphics (via nvidia-drm) | planned |
| NVIDIA580 ␀ | nvidia+modeset+drm (580) | Maxwell/Pascal/Volta (900/1000) | 0x10de:* (580 list) | IOGraphics | planned |
| NVIDIALegacy470 ␀ | nvidia + nvidia-modeset (470) | Kepler (600/700) | 0x10de:* (470 list) | — (no KMS bridge; X11 only) | planned |
| NVIDIALegacy390 ␀ | nvidia (390) | Fermi (400/500) | 0x10de:* (390 list) | — (X11 only) | planned |
| NVIDIALegacy340 ␀ | nvidia (340) | Tesla (8/9/200/300) | 0x10de:* (340 list) | — (X11 only) | planned |
| NVIDIALegacy304 ␀ | nvidia (304) | GeForce 6/7 (Curie) | 0x10de:* (304 list) | — (X11 only) | planned |
The CI test (bochs, the clean case). Boot the continuous image headless with qemu’s default -vga std. The device goes unmatched → device_nomatch → the IOKit matcher reads IOPCIPrimaryMatch → kextd kextloads BochsGraphics.kext → MODULE_DEPEND pulls drmn/ttm/drm_extra_helpers in order → driver attaches. Assertions: kextstat shows it loaded; dmesg shows drmn/bochs attach + [drm] fb + connector init; /dev/dri/card0 exists; sysctl dev.drmn.0 present; no panic. This is the first time the path is exercised against a device that actually appears. Watch two attach pitfalls: the aperture/vgaarb handoff (must release the boot/efifb framebuffer or the driver fights the console — a common KMS hang), and (virtio only) ensuring the DRM driver out-scores FreeBSD base’s native non-DRM virtio_gpu(4) scanout driver.
NVIDIA is its own repo — not because of the kext mechanics (those are identical) but because of licensing and build shape. The idea: repackage only the kernel modules needed to load for X11/KMS — no libGL, no X driver, no Vulkan ICD — as per-legacy-branch kexts.
nvidia.ko — the proprietary core (open OS-shim recompiled + a precompiled nv-kernel.o blob), exposing its own /dev/nvidia char interface. Not a DRM driver; does not use drm.ko.nvidia-modeset.ko — kernel modesetting (NvKmsKapi).nvidia-drm.ko — the DRM/KMS bridge that registers with and links the same drm.ko/drmn core this plan’s IOGraphics.kext provides (MODULE_DEPEND(nvidia_drm, drmn, 2,2,2)). FreeBSD even split the port: x11/nvidia-driver (userland) → x11/nvidia-kmod (the .kos) + graphics/nvidia-drm-kmod (the bridge).The licensing constraint NVIDIA’s redistribution exception blesses only the unmodified binary package. But a KBI-correct nvidia.ko for the NextBSD kernel is recompiled (the open shim rebuilt against /usr/src/sys, then linked with the blob) — arguably a new binary outside that exception. So the repo hosts no NVIDIA binaries: it is a recipe (like a FreeBSD port) that fetches NVIDIA’s unmodified tarball at build time and compiles against the local kernel, then wraps the three .kos as a kext. This is a fundamentally different publish/ingest model from the open kexts (which publish prebuilt .kexts to continuous) — and the decisive reason NVIDIA is a sibling repo, not a job inside nextbsd-graphics.
One kext per FreeBSD nvidia-kmod* port. FreeBSD ships the current driver plus five pinned legacy branches; each becomes a kext carrying that branch’s .kos and its own supported-GPU match table. Crucially, the DRM/KMS bridge (graphics/nvidia-drm-612-kmod, pinned to NextBSD’s drm 6.12 core — see the note in §5) is packaged only for the main and 580 branches; the four older branches are core / X11-only (proprietary /dev/nvidia path, no /dev/dri, no Wayland), so only main/580 depend on IOGraphics.
| FreeBSD port | Branch | GPU generation(s) | DRM/KMS bridge (drm 6.12) | → Kext |
|---|---|---|---|---|
x11/nvidia-kmod | main / current | Turing+ (RTX 20xx → Blackwell) | yes nvidia-drm-612-kmod | NVIDIA.kext |
x11/nvidia-kmod-580 | 580.xx | Maxwell / Pascal / Volta (GTX 900/1000) | yes nvidia-drm-612-kmod-580 | NVIDIA580.kext |
x11/nvidia-kmod-470 | 470.xx | Kepler (GeForce 600/700) | no — X11 only | NVIDIALegacy470.kext |
x11/nvidia-kmod-390 | 390.xx | Fermi (GeForce 400/500) | no | NVIDIALegacy390.kext |
x11/nvidia-kmod-340 | 340.xx | Tesla (GeForce 8/9/200/300) | no | NVIDIALegacy340.kext |
x11/nvidia-kmod-304 | 304.xx | GeForce 6/7 (Curie / NV4x–G7x) | no | NVIDIALegacy304.kext |
(x11/nvidia-kmod-devel is the beta track — an optional NVIDIADevel.kext if wanted.) Matching: vendor 0x10de; a gen-nvidia-personalities parses each branch’s supportedchips.html (NVIDIA’s own per-branch device table) into a branch-specific IOPCIPrimaryMatch list (NVIDIA’s ids are non-contiguous, so exact lists, not ranges). Biggest blocker: the same linuxkpi/DRM KBI fragility — nvidia-drm.ko must be commit-matched to the drm 6.12 core, which is why build-from-source (not a stock pkg .ko) is mandatory. The maintainer accepts rebuilding the NVIDIA ports against drm 6.12 as part of this track.
One plan, but the heterogeneity (open build-from-source vs. NVIDIA recipe-with-blob) is real, so it lands as three repos, with the per-driver-class differences expressed as jobs/subdirs inside the open one rather than a repo explosion:
| Repo | Role | Publishes |
|---|---|---|
nextbsd-redux/drm-kmod | Unmodified, SHA-pinned mirror of freebsd/drm-kmod (the core + intel/amd/radeon source). Kept clean for rebasing. | nothing (a source dep) |
nextbsd-redux/nextbsd-graphics | The open kext factory. Vendors the new drivers (bochs/vboxvideo/virtio/vmwgfx) + drm_extra_helpers.ko; builds them and wraps drm-kmod’s intel/amd/radeon, all via the shared ko2kext/gen-personalities toolchain. | prebuilt .kexts → continuous |
nextbsd-redux/nextbsd-nvidia (name TBD) | The NVIDIA recipe (proprietary, per-legacy-branch). Builds on-target/at-build-time; hosts no binaries. | a port/recipe, not binaries |
Naming: nextbsd-graphics reads cleaner than nextbsd-graphics-modules (these are kexts, not kld modules, and “modules” collides confusingly with nextbsd-kernel-modules). The fork stays plainly drm-kmod. Migration: the current IntelGraphics/AMDGraphics/RadeonGraphics kext work stays in nextbsd-kernel-modules for now; the roadmap migrates it into nextbsd-graphics once that repo exists, so nothing has to move all at once.
nextbsd-graphics; pin the drm-kmod fork by SHA (submodule); decide submodule layout (it dictates every Makefile’s -I block).drm_extra_helpers.ko: vendor + compile drm_simple_kms_helper.c (low risk first), then drm_gem_vram_helper.c (the TTM-coupled blocker); wire in drm_format_helper.c.bochs.c; write its bsd.kmod.mk + bochs_freebsd.c glue; resolve DISPI MMIO/io-port + the aperture handoff.kldload, and bind under qemu -vga std; chase the “binds but black screen” symptom in the VRAM helper to a working KMS console.ko2kext + gen-bochs-personalities.sh → BochsGraphics.kext; add the qemu -vga std line + /dev/dri/card0 + kextstat + dmesg assertions to CI. First end-to-end graphics CI test.vboxvideo + HGSMI; MODULE_DEPEND on drm_extra_helpers; VBoxGraphics.kext on 80ee:beef. Optional VirtualBox-guest CI if a runner exists.linuxkpi virtio bridge: revive linux_virtio.c, fix the compile errors, implement the panic()-stubbed reset/del_vqs, settle the virtio_driver probe model. This is the dominant cost.drm_gem_shmem_helper.c into drm_extra_helpers.ko; re-port the 5.5→6.6 virtgpu deltas.virtgpu_*.c set + glue; new IOKit-matcher plumbing for the virtio sub-bus; ensure the DRM driver beats base virtio_gpu(4).-device virtio-gpu-pci; assert bind + /dev/dri/card0 + renderD128. Descope virgl/3D.ttm_object.c); stub vmwgfx_page_dirty.c for a first cut; VMwareGraphics.kext on 15ad:0405.nextbsd-nvidia as a recipe (fetch unmodified tarball at build; compile nvidia-kmod against the NextBSD kernel; wrap the 3 .kos); start with branch 470 (Kepler), then 390/340; gen-nvidia-personalities from supportedchips.html.drm_gem_vram_helper (bochs/vbox) and drm_gem_shmem_helper (virtio) are absent from drm-kmod and the ravynsoft fork; the kernel-baked linuxkpi was never exercised for them, so the first build surfaces a cascade of missing symbols. The VRAM helper’s TTM coupling yields exactly the “binds but black screen” of drm-kmod issue #62.linuxkpi virtio layer exists; the prototype is against 5.5, doesn’t compile, and panic()s on the mandatory reset/del_vqs. Its scatterlist→sglist conversion and interrupt-context casts are likely buggy under real traffic.IOPCIDevice), so the cleanest end-to-end CI demonstration is bochs, not virtio..ko posture with NVIDIA’s driver-licensing@nvidia.com before any release.page_dirty leans on Linux MM internals linuxkpi doesn’t expose; correct (un-stubbed) support may require touching linuxkpi VM-fault handling. kmap_atomic_prot is x86-specific — an arm64 target needs more.Open questions to settle first:
nextbsd-graphics (dictates every Makefile’s -I block).IOPCIPrimaryMatch honor the full 4-tuple (subvendor/subdevice), or only vendor/device? bochs ideally keys on subsystem 1af4:1100 to avoid grabbing non-qemu 1234:1111.CONFIG_DRM_FBDEV_EMULATION? Without it KMS may work but the fbdev console is absent.virtio_gpu(4).LINUXKPI_VERSION 60600) and the CI rule that rebuilds both together.Research scope: 5-agent virtual-GPU workflow (bochs/virtio-gpu/vmwgfx + build architecture + CI/kext/nvidia-drm) + dedicated VirtualBox-vboxvideo and NVIDIA-legacy studies. Primary sources: Linux 6.6 drivers/gpu/drm (tiny/bochs.c, virtio/, vmwgfx/, vboxvideo/), freebsd/drm-kmod (incl. issues #62/#356 and the removed vboxvideo/vmwgfx), ravynsoft/drm-kmod branch virtio (PR #119), freebsd-ports (x11/nvidia-kmod, graphics/nvidia-drm-kmod, emulators/virtualbox-ose-additions), and NVIDIA’s per-branch supportedchips.html + redistribution license. A plan, not a promise — the GEM-helper port and the virtio KPI bridge are the two pieces that decide the schedule.