A good update. The VIRTIO_NET_F_MTU negotiation has been a roadblock for many guest OS implementations on apple's virtualization stack. The spec is vague enough that linux just does it while openbsd had to explicitly patch in support to handle the hypervisor's hardmtu limit.
This is a big deal for local development imho. With the raw single-thread performance of the M4/M5 chips, an openbsd guest is arguably the best environment for testing pf configurations or running isolated mail servers (for example). Being able to rely on viogpu without the black-screen-of-death means we can slowly move away from serial console-only installs for quick VMs.
Big kudos to Helg and Stefan!
The bigger news is that this also fixes the QEMU compatibility bug that makes OpenBSD hang out of the box on arm64 when starting X.
It started in 7.3 with the frame buffer changes and the only workaround was to disable the kernel driver.
Maybe more people will get to try out OpenBSD successfully now.
Note that this is about Virtualization.framework (Apple's first party VMM). OpenBSD worked on Hypervisor.framework + qemu since a very long time.
Is there a guide on how to do this? I haven’t ever used the raw hypervisor.
A good update. The VIRTIO_NET_F_MTU negotiation has been a roadblock for many guest OS implementations on apple's virtualization stack. The spec is vague enough that linux just does it while openbsd had to explicitly patch in support to handle the hypervisor's hardmtu limit.
This is a big deal for local development imho. With the raw single-thread performance of the M4/M5 chips, an openbsd guest is arguably the best environment for testing pf configurations or running isolated mail servers (for example). Being able to rely on viogpu without the black-screen-of-death means we can slowly move away from serial console-only installs for quick VMs.
Big kudos to Helg and Stefan!
The bigger news is that this also fixes the QEMU compatibility bug that makes OpenBSD hang out of the box on arm64 when starting X.
It started in 7.3 with the frame buffer changes and the only workaround was to disable the kernel driver.
Maybe more people will get to try out OpenBSD successfully now.
Note that this is about Virtualization.framework (Apple's first party VMM). OpenBSD worked on Hypervisor.framework + qemu since a very long time.
Is there a guide on how to do this? I haven’t ever used the raw hypervisor.
a quick kagi search revealed this: https://briancallahan.net/blog/20250222.html, perhaps it might work for you too ?
It should just be a matter of producing a kernel and, if necessary, RAM disk that can be booted the same way as Linux.
No X and networking. What's the point then? Useless imo