OpenBSD-current ahora puede ejecutarse como invitado en Apple Hypervisor

• OpenBSD/arm64 ahora puede funcionar como sistema operativo invitado en el entorno de Apple Hypervisor
• A través de una serie de commits, se corrigieron y mejoraron el procesamiento gráfico y las funciones de red, resolviendo el pánico del kernel y el problema de pantalla negra en X11
• Ahora funciona completamente en el entorno de Apple Virtualization y puede usarse en las Mac Apple Silicon más recientes

---

Soporte de OpenBSD/arm64 en Apple Hypervisor

• Gracias a commits recientes, OpenBSD/arm64 puede ejecutarse como sistema operativo invitado en Apple Hypervisor
  • Los commits relacionados fueron realizados por Helg Bredow(helg@) y Stefan Fritsch(sf@)

Corrección de viogpu por Helg Bredow

• Se modificó la función viogpu_wsmmap() en el archivo sys/dev/pv/viogpu.c
  • Antes devolvía una dirección virtual del kernel (kva), pero ahora devuelve una dirección física mediante bus_dmamem_mmap(9)
  • Esta corrección resuelve el problema de pantalla negra al ejecutar X11 en QEMU y el pánico del kernel en Apple Hypervisor
• Se agregó una llamada a bus_dmamap_sync(9) antes de transferir el framebuffer a la memoria del host
  • Esto permite que el host que se ejecuta en otra CPU detecte las actualizaciones del framebuffer
  • La revisión y los comentarios sobre la corrección estuvieron a cargo de kettenis@, y la aprobación (ok) fue dada por sf@

Corrección de red virtio por Stefan Fritsch

• Se agregó soporte para la función VIRTIO_NET_F_MTU en el archivo sys/dev/pv/if_vio.c
  • Obtiene el valor de hardmtu desde el hipervisor y configura el MTU actual con ese mismo valor
  • Aunque el estándar de virtio no es del todo claro, se adoptó el mismo enfoque que Linux
• Se usa ETHER_MAX_HARDMTU_LEN como límite superior, lo que ofrece un manejo más preciso que el anterior MAXMCLBYTES
  • Si el hipervisor solicita un MTU mayor que ese valor, se realiza una renegociación sin la función VIRTIO_NET_F_MTU
• Con este commit, OpenBSD funciona completamente en el entorno de Apple Virtualization
  • Las aportaciones y pruebas fueron realizadas por helg@, y la aprobación (ok) fue dada por jan@

Guía para usuarios y recomendación de pruebas

• Este cambio es especialmente útil para los usuarios de los modelos más recientes de Mac con Apple Silicon
• Actualmente puede probarse en la versión snapshot, y se solicita retroalimentación de los usuarios

[GN⁺]

Opiniones en Hacker News

• Buena actualización. La negociación de VIRTIO_NET_F_MTU había sido un obstáculo para varias implementaciones de sistemas operativos invitados en la pila de virtualización de Apple
  Como la especificación es ambigua, Linux simplemente funciona, pero OpenBSD tuvo que agregar un parche aparte para manejar los límites duros de MTU
  Gracias al rendimiento de un solo hilo de los chips M4/M5, los invitados OpenBSD son un entorno ideal para probar configuraciones de pf o ejecutar un servidor de correo aislado
  Ahora que se puede usar viogpu de forma estable, ya no hace falta depender solo de la consola serial al hacer instalaciones rápidas de VM
  Un gran aplauso para Helg y Stefan
  • Quizá sería todavía mejor con un unikernel. Aunque en ese caso haría falta un unikernel para servidor de correo que pueda funcionar sin sistema operativo
  • Yo no necesito ese entorno gráfico. Mi IaC (infraestructura como código) no quiere ninguna interacción al levantar una VM
• La noticia más importante es que esta actualización resolvió un bug de compatibilidad con QEMU
  Por ese bug, OpenBSD se quedaba colgado al iniciar X en arm64, un problema que apareció después de los cambios al framebuffer en la versión 7.3
  La única solución era desactivar el controlador del kernel, pero ahora parece que más gente podrá probar OpenBSD sin problemas
  • Yo soy uno de ellos. Desde hace tiempo quería probarlo, pero mi única máquina es una MacBook Pro
  • Me pregunto por qué QEMU tendría que iniciar X. ¿No se supone que eso le corresponde a OpenBSD?
• Esto se refiere a Virtualization.framework (el VMM de Apple de 1st-party)
  OpenBSD ya funcionaba desde hace tiempo con la combinación Hypervisor.framework + QEMU
  • El nombre es demasiado confuso. Casi es imposible distinguir entre los dos frameworks
  • No estoy seguro, pero ¿eso se introdujo en Tahoe? Me da curiosidad saber qué resolvió algo que antes no era posible
  • Yo también me confundí. UTM usa QEMU internamente, pero ahora el snapshot de OpenBSD arranca sin problemas en QEMU. Sigue siendo virtualizado de todos modos
• Puede que se me esté escapando algo, pero al probar VM había un problema donde, una vez que la memoria aumentaba, nunca volvía a reducirse
  Si eso es un problema real, me pregunto si hubo mejoras
  • Hacer que el invitado le diga al host “ya liberé completamente esta memoria, así que puedes recuperarla” es bastante complejo
    En cambio, es mucho más simple que el invitado crea que tiene 4 GiB de RAM cuando en realidad el host solo la asigna al momento de acceder a ella
    Las VM son algo completamente distinto de los contenedores
  • Me pregunto dónde probaste la VM. Todos los días corren cientos de millones de VM en todo el mundo
• ¿Habrá alguna guía para hacer esto directamente? Nunca he usado un hypervisor raw
  • Con una búsqueda rápida en Kagi encontré esta entrada de blog. Tal vez pueda ayudar
  • Básicamente, haces el kernel y, si hace falta, un disco RAM, y luego arrancas como en Linux
• Es un poco relacionado, pero UTM Remote es de verdad un excelente cliente remoto para VM
  Ojalá también soportara otros protocolos de hypervisor (libvirtd, bhyve, etc.)
• Me pregunto si OpenBSD es lo bastante seguro cuando corre como invitado
  Quiero saber si queda aislado al punto de que el host no pueda comprometerlo ni matemáticamente. Podría ser ideal para manejo de claves
  • A partir de 2025, OpenBSD soporta AMD SEV/SEV-ES, y SEV-SNP está en desarrollo
    Con el hardware adecuado, el aislamiento sí es posible
    Esto también se trata en la charla de BSDCan 2025
  • Pero el kernel del host y el VMM todavía pueden ver la memoria del invitado. No lo recomendaría para ese uso
• Como referencia, este fork de Redox está hecho completamente en Rust y no tiene ningún Makefile
• ¡Bien hecho! Actualmente FreeBSD 15 no logra hacer funcionar X en UTM
  En este momento solo se puede usar RDP/VNC, así que espero que con esta mejora también pueda funcionar el framebuffer