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.

Maybe I am missing something but the last few times I tested VMs it seemed to end up never shrinking in RAM size once it had grown, is this a real issue and if so is there any improvement coming on that front?

Is there a guide on how to do this? I haven’t ever used the raw hypervisor.

undefined

Well done! FreeBSD 15 is a complete no-go for X right now on utm, rdp/vnc is the only way. Hopefully somebody will work out how to get a frame buffer working there, from this.

I wonder if openbsd is secure running as a guest ? it it able to isolate it-self sufficiently so that the host cannot mathematically breach it ? (which makes openbsd very suitable for keyholding)

On a slightly related note UTM remote is such a nice remote client for VMs that I wish they would make it compatible with other hypervisor protocols such as libvirtd and bhyve.

This is a significant milestone for OpenBSD on Apple hardware. The improved support for Virtualization.framework will definitely make local development and testing much smoother for many users. Kudos to the developers!

so does redox at least this fork: https://github.com/pannous/redox completely Rust-based without any Makefiles.

[dead]

[dead]

No X and networking. What's the point then? Useless imo