lileding

VMM Core API And Frontends

DragonFly Virtualization Stack

DragonFly virtualization is one layered stack, not a replacement for every virtual-machine use case. vmm(4) is the common kernel backend. nvmm(4) and vmmfs(5) are deliberately different management frontends over that same backend: the former preserves an exit-driven userspace-monitor model; the latter provides a declarative, modern PCIe-only kernel-managed model.

lileding

dfvmm Design

1. Design Goal

dfvmm is a DragonFly BSD virtualization stack for efficient container services whose isolation unit is a virtual machine. A container sandbox receives a real hardware-virtualized guest kernel and a deliberately small modern I/O surface. The goal is strong VM isolation with a short, efficient path from an OCI task to guest execution.

lileding

DragonFly BSD: loading firmware from files instead of kernel modules - design and migration plan

Firmware loading in DragonFly BSD

The firmware framework stays where it is. firmware(9), firmware_get(), firmware_register() and the drivers that call them are unchanged. What the framework gains is one new capability: it can read a firmware image straight out of a file, without that image having first been wrapped in a kernel module. Modules keep working exactly as they do today, and a driver that has not been touched notices nothing.

lileding

Which Mesa versions will talk to an old amdgpu? A survey of the DRM version gate

Mesa's AMD code refuses to initialise below a minimum amdgpu uAPI version, and that minimum has been raised four times. If you maintain an out-of-tree or downstream amdgpu — a BSD port, a vendor fork, a frozen kernel — this decides which Mesa releases you can ship, and the answer is not "whatever is current".

Everything below was extracted mechanically from a full Mesa clone (226783 commits, 944 tags) and from Linux's amdgpu_drv.c version log. The extraction points are documented at the end so the numbers can be re-derived rather than