Call for testing: OpenBSD vmm(4)/vmd(8) fd-ification

Thanks to the tireless work of among others Dave Voutila (dv@), development of the OpenBSD/amd64 virtualization system vmm(4)/vmd(8) continues to make progress.

Now breaking changes, but with with potential benefits in both process isolation and compartmentalization of functionality, are on the way. It almost goes without saying that this code needs testing.

In a message to the tech@ mailing list with the subject tests wanted: vmm(4)/vmd(8) fd-ification, Dave Voutila presents the code along with some explanation:

List:       openbsd-tech
Subject:    tests wanted: vmm(4)/vmd(8) fd-ification
From:       Dave Voutila <dv () sisu ! io>
Date:       2026-08-03 14:36:00
Message-ID: 87a4r3fezz.fsf () mars ! sisu ! io

Calling on vmm(4)/vmd(8) users to give this diff a test please!

This is a major breaking change I'm proposing to land soon. It changes
the vmm(4) design to create a new file type for each VM. When a VM is
created, the caller gets a new file descriptor for using ioctl(2) calls
against that VM.

This fundamentally changes the design from knowing a "magic number"
(today, the vm id) to possessing a capability (the open file
descriptor).

Why do this?

 - Better isolate which process can manipulate a VM. Today it's a hacky
   combination of knowing the magic number and vmm(4)tracking an owning
   PID. The current design scares me.

 - Better scope the vmm(4) API into basically a control plane vs. data
   plane design. A privileged process with an open /dev/vmm special file
   can launch/terminate VMs, but the manipulation of each VM and VCPU is
   done via its own dedicated file.

 - Using files helps simplify the lifecycle management of VMs in the
   kernel by tying their lifetime to a file. vmd(8) processes emulating
   the VM will have their file descriptor closed by the kernel even if
   the process is killed (e.g. via segfault). This simplifies cleanup of
   dead VMs.

Bonus: there's a slight chance this improves perf slightly, but since
that's not the goal I'm not benchmarking. Given a new ioctl(2) path for
the new VM file type, it may reduce contention on the kernel lock.

Note: this is unlike Linux/KVM which uses not only a file per VM, but
one per VCPU. I see no reason for that level of complication at the moment.

I don't expect detailed review yet given the size of this. I plan on
sending separate mails breaking this down into kernel vs. userland (the
userland stuff is a lot of deck chair shuffling) as well as updates to
vmm.4 man page and fstat(1).

To test:

1. build and install new kernel and reboot
2. symlink (recommended) or install headers in /usr/include:
     amd64/vmmvar.h --> sys/arch/amd64/include/vmmvar.h
     dev/vmm/vmm.h --> sys/dev/vmm/vmm.h
     dev/ic/pspvar.h --> sys/dev/ic/pspvar.h
3. build and install vmd(8) and vmctl(8) (if this fails, check your
   headers in /usr/include/ point to the patched ones in the tree)
4. run your existing VMs...you should see no discernable difference in
   behavior.

If things break or behavior changes, please report to me including:

* cpu0 details from dmesg(1)
* details on how the vm is started (/etc/vm.conf contents or vmctl(8)
  args)
* vmd(8) debug output if any (try running vmd in the foreground via
  something like: # $(which vmd) -dvv

** I specifically need help testing SEV-related usage as I have no
commercial grade AMD hardware with all the cool SEV stuff. **

Once I land this I'll no longer lose sleep worrying about the current
design and can turn my attentions to MMIO/instruction emulation needed
for getting to SMP ;)

Thanks!

following this explanation, you will find the patch (against -current) that implements the changes.

If you are able to test, please do. Dave and others will very much appreciate reports on how the new code behaves in environments that are not the original developers' ones.