TL;DR
A pair of commits to OpenBSD's pv drivers enable OpenBSD/arm64 to run as a guest under Apple Hypervisor. Changes fix a framebuffer mapping bug that could panic the kernel and add virtio network MTU handling, and the work is available in snapshots for testing.
What happened
Developers Helg Bredow and Stefan Fritsch committed changes to OpenBSD's paravirtual device drivers that allow OpenBSD/arm64 to operate as a guest under Apple Hypervisor. The viogpu driver was modified so that viogpu_wsmmap() returns a physical address via bus_dmamem_mmap(9) rather than a kernel virtual address; bus_dmamap_sync(9) calls were also added to ensure framebuffer updates are visible to a host running on another CPU. Those fixes address a black screen in QEMU and a kernel panic on the Apple Hypervisor. Separately, the virtio network driver now supports the VIRTIO_NET_F_MTU feature so the guest can use the hypervisor-provided hard MTU; the code sets the current MTU to that value, applies ETHER_MAX_HARDMTU_LEN as an upper limit, and will redo feature negotiation if the hypervisor requests a larger MTU. The commits are in the repository and the changes are available in snapshots; contributors and reviewers are credited in the commit messages.
Why it matters
- Enables OpenBSD/arm64 to run as a guest under Apple Hypervisor, widening virtualization options on newer Apple Silicon Macs.
- Fixes a framebuffer mapping issue that could cause kernel panics when running under Apple Hypervisor.
- Adds virtio network MTU support so guests can honor the hypervisor's hard MTU, improving network interoperability.
- Available in snapshots, allowing users with appropriate hardware to test and report issues prior to formal releases.
Key facts
- Two recent commits modified files under sys/dev/pv: viogpu.c and if_vio.c.
- Helg Bredow committed changes to viogpu.c on 2026-01-12 addressing framebuffer mapping and synchronization.
- Stefan Fritsch committed changes to if_vio.c on 2026-01-15 to add VIRTIO_NET_F_MTU support and MTU negotiation logic.
- viogpu_wsmmap() was changed to return a physical address via bus_dmamem_mmap(9) instead of a kernel virtual address.
- bus_dmamap_sync(9) calls were added before transferring framebuffer data to host memory to ensure visibility.
- Virtio network support now requests the hypervisor hard MTU, sets the guest MTU to that value, and uses ETHER_MAX_HARDMTU_LEN as an upper limit.
- If the hypervisor requests an MTU larger than ETHER_MAX_HARDMTU_LEN, the driver redoes feature negotiation without VIRTIO_NET_F_MTU.
- Commit messages credit kettenis@ for review and note input/testing from helg; messages conclude with 'ok' acknowledgments from reviewers.
- The maintainers say the changes make OpenBSD work on Apple Virtualization and that the code is available in snapshots for testing.
What to watch next
- Reports from users testing the OpenBSD/arm64 snapshots under Apple Hypervisor to verify stability and interoperability.
- not confirmed in the source
Quick glossary
- Apple Hypervisor: Apple's virtualization framework and hypervisor for running guest operating systems on macOS, including on Apple Silicon hardware.
- VIRTIO_NET_F_MTU: A virtio network feature flag that allows a hypervisor to advertise a 'hard MTU' value to the guest for MTU configuration.
- bus_dmamem_mmap / bus_dmamap_sync: Bus DMA helper routines used by kernels to map device memory for DMA and to synchronize CPU/cache state with device-visible memory.
- Framebuffer: A region of memory containing the pixel data that represents what is displayed on a screen; used by virtual GPUs to present graphical output to hosts or guests.
- Snapshot: A development or pre-release build of an operating system tree that includes recent commits and is intended for testing rather than official stable releases.
Reader FAQ
Can I run OpenBSD on Apple Silicon under Apple Hypervisor now?
According to the commits, OpenBSD/arm64 now works as a guest under Apple Hypervisor and the changes are in snapshots.
What code changes fixed the kernel panic and black screen?
The viogpu driver was changed so viogpu_wsmmap() returns a physical address via bus_dmamem_mmap(9) and bus_dmamap_sync(9) calls were added before copying the framebuffer.
Did networking behavior change for virtio guests?
Yes. The virtio network driver added support for VIRTIO_NET_F_MTU, sets the guest MTU to the hypervisor's hard MTU, and enforces ETHER_MAX_HARDMTU_LEN as an upper bound.
Where can I test these changes?
The article says the fixes are available in snapshots and asks users with the hardware and capacity to try them and report back.
Contributed by Peter N. M. Hansteen on 2026-01-15 from the hyper-armed dept. Following a recent series of commits by Helg Bredow (helg@) and Stefan Fritsch (sf@), OpenBSD/arm64 now works as…
Sources
Related posts
- Analyst Jeff Pu Details Hardware Expectations for Apple’s iPhone Fold and iPhone 18 Line
- Gambit: Open-source agent harness for composing reliable, testable LLM workflows
- India’s antitrust watchdog issues final warning to Apple over investigation delays