hey, i tried setting up microsandbox inside the vm, but it cannot run because /dev/kvm is missing.
i am running an m5 max on macos 26.3, so the host supports nested virtualization. the current try omarchy runtime appears to pin qemu 10.2.50 and launches with:
-machine virt,accel=hvf,gic-version=2
qemu 11.1 recently added nested virtualization and vgic support to the arm hvf accelerator. from what i understand, the required configuration should be around:
-machine virt,accel=hvf,virtualization=on,gic-version=3
the included arch linux arm kernel also appears to have kvm enabled already, so the main missing piece seems to be exposing virtual el2 through qemu/hvf.
this is what i currently get:
would you be open to supporting nested virtualization as an opt-in feature on compatible m3 and newer macs?
the expected result would be for /dev/kvm to appear inside the guest and for msb doctor to pass its kvm check.
i realize this probably requires upgrading qemu, moving from gicv2 to the hvf-backed gicv3 path, and retesting the existing cocoa, virgl, display, and audio patches. the current 4 gib guest memory allocation may also be tight for nested workloads, so a configurable memory option could be useful alongside this.
hey, i tried setting up microsandbox inside the vm, but it cannot run because
/dev/kvmis missing.i am running an m5 max on macos 26.3, so the host supports nested virtualization. the current try omarchy runtime appears to pin qemu 10.2.50 and launches with:
qemu 11.1 recently added nested virtualization and vgic support to the arm hvf accelerator. from what i understand, the required configuration should be around:
the included arch linux arm kernel also appears to have kvm enabled already, so the main missing piece seems to be exposing virtual el2 through qemu/hvf.
this is what i currently get:
would you be open to supporting nested virtualization as an opt-in feature on compatible m3 and newer macs?
the expected result would be for
/dev/kvmto appear inside the guest and formsb doctorto pass its kvm check.i realize this probably requires upgrading qemu, moving from gicv2 to the hvf-backed gicv3 path, and retesting the existing cocoa, virgl, display, and audio patches. the current 4 gib guest memory allocation may also be tight for nested workloads, so a configurable memory option could be useful alongside this.