OpenBSD-current peut désormais fonctionner comme invité sur Apple Hypervisor

• OpenBSD/arm64 peut désormais fonctionner comme système d’exploitation invité dans l’environnement Apple Hypervisor
• Une série de commits a corrigé et amélioré le rendu graphique et les fonctions réseau, résolvant les problèmes de kernel panic et d’écran noir sous X11
• Il fonctionne désormais complètement dans l’environnement Apple Virtualization et peut être utilisé sur les Mac Apple Silicon les plus récents

---

Prise en charge d’OpenBSD/arm64 sur Apple Hypervisor

• De récents commits permettent à OpenBSD/arm64 de s’exécuter comme système invité sur Apple Hypervisor
  • Les commits concernés ont été réalisés par Helg Bredow(helg@) et Stefan Fritsch(sf@)

Correctifs viogpu par Helg Bredow

• Dans le fichier sys/dev/pv/viogpu.c, la fonction viogpu_wsmmap() a été modifiée
  • Auparavant, elle renvoyait une adresse virtuelle du noyau (kva), mais elle renvoie désormais une adresse physique via bus_dmamem_mmap(9)
  • Ce correctif résout le problème d’écran noir lors de l’exécution de X11 sur QEMU ainsi que les kernel panic sur Apple Hypervisor
• Ajout d’un appel à bus_dmamap_sync(9) avant le transfert du framebuffer vers la mémoire hôte
  • Cela permet à l’hôte exécuté sur un autre CPU de détecter les mises à jour du framebuffer
  • La revue du correctif et les retours ont été assurés par kettenis@, et l’approbation (ok) a été donnée par sf@

Correctifs réseau virtio par Stefan Fritsch

• Ajout de la prise en charge de la fonctionnalité VIRTIO_NET_F_MTU dans le fichier sys/dev/pv/if_vio.c
  • La valeur hardmtu est récupérée depuis l’hyperviseur afin de définir la MTU actuelle à la même valeur
  • Même si le standard virtio n’est pas explicite sur ce point, l’implémentation adopte la même approche que Linux
• ETHER_MAX_HARDMTU_LEN est utilisé comme limite supérieure, pour un traitement plus précis que l’ancien MAXMCLBYTES
  • Si l’hyperviseur demande une MTU supérieure à cette limite, une renégociation sans la fonctionnalité VIRTIO_NET_F_MTU est effectuée
• Avec ce commit, OpenBSD fonctionne désormais complètement dans l’environnement Apple Virtualization
  • La contribution et les tests ont été assurés par helg@, et l’approbation (ok) a été donnée par jan@

Informations aux utilisateurs et recommandation de test

• Ce changement est particulièrement utile aux utilisateurs des modèles récents de Mac Apple Silicon
• Il peut actuellement être testé dans la version snapshot, et les retours des utilisateurs sont sollicités

[GN⁺]

Commentaires sur Hacker News

• Excellente mise à jour. La négociation VIRTIO_NET_F_MTU bloquait plusieurs implémentations d’OS invités dans la pile de virtualisation d’Apple
  La spécification étant ambiguë, Linux fonctionne simplement, mais OpenBSD a dû ajouter un correctif séparé pour gérer les limites MTU matérielles
  Grâce aux performances mono-thread des puces M4/M5, un invité OpenBSD offre un environnement idéal pour tester des configurations pf ou faire tourner un serveur mail isolé
  On peut désormais utiliser viogpu de façon fiable, ce qui permet de sortir du mode console série uniquement utilisé jusqu’ici pour les installations rapides de VM
  Un grand bravo à Helg et Stefan
  • Un unikernel serait peut-être encore mieux. Mais dans ce cas, il faudrait un unikernel pour serveur mail capable de fonctionner sans OS
  • Je n’ai pas besoin d’un tel environnement graphique. Mon IaC (infrastructure as code) ne veut aucune interaction au démarrage d’une VM
• La nouvelle la plus importante, c’est que cette mise à jour corrige un bug de compatibilité QEMU
  À cause de lui, OpenBSD se figeait au démarrage de X sur arm64, un problème apparu après des changements du framebuffer dans la version 7.3
  La seule solution consistait à désactiver le pilote du noyau, donc davantage de personnes devraient désormais pouvoir essayer OpenBSD sans problème
  • J’en fais partie. J’avais envie de l’essayer depuis un moment, mais ma seule machine est un MacBook Pro
  • Je me demande pourquoi QEMU devrait démarrer X. J’aurais pensé que c’était le rôle d’OpenBSD
• Il s’agit de Virtualization.framework (le VMM first-party d’Apple)
  OpenBSD fonctionnait déjà depuis longtemps avec la combinaison Hypervisor.framework + QEMU
  • Les noms sont vraiment trop confus. Il est presque impossible de distinguer les deux frameworks
  • Je ne suis pas sûr, mais ça a été introduit dans Tahoe ? Je me demande ce qui a permis de résoudre quelque chose qui ne l’était pas auparavant
  • Moi aussi, j’étais perdu. UTM utilise QEMU en interne, mais désormais un snapshot OpenBSD démarre proprement dans QEMU. Cela reste malgré tout de la virtualisation
• J’ai peut-être raté quelque chose, mais quand je testais des VM, il y avait un problème où, une fois la mémoire augmentée, elle ne redescendait jamais
  Si c’est un vrai sujet, je me demande s’il y a eu des améliorations
  • Faire en sorte que l’invité dise à l’hôte « cette mémoire est entièrement libérée, vous pouvez la récupérer » est assez complexe
    À l’inverse, il est bien plus simple que l’invité croie disposer de 4 Gio de RAM alors que l’hôte n’alloue réellement la mémoire qu’au moment de l’accès
    Une VM n’a rien à voir avec un conteneur
  • Je me demande où vous avez testé des VM. Des centaines de millions de VM tournent chaque jour dans le monde
• Existe-t-il un guide pour faire ça soi-même ? Je n’ai jamais utilisé un hyperviseur brut
  • Une recherche rapide sur Kagi m’a mené à ce billet de blog. Ça pourra peut-être aider
  • En gros, il suffit de créer le noyau et, si nécessaire, un disque RAM, puis de démarrer comme sous Linux
• C’est un peu lié, mais UTM Remote est un excellent client distant pour VM
  J’aimerais qu’il prenne aussi en charge d’autres protocoles d’hyperviseurs (libvirtd, bhyve, etc.)
• Je me demande si OpenBSD est suffisamment sûr lorsqu’il tourne comme invité
  J’aimerais savoir s’il est isolé au point que l’hôte ne puisse pas le compromettre mathématiquement. Cela pourrait être idéal pour la gestion de clés
  • En 2025, OpenBSD prend en charge AMD SEV/SEV-ES, et SEV-SNP est en cours de développement
    Avec le matériel adéquat, une isolation suffisante est possible
    Le sujet est également abordé dans cette présentation BSDCan 2025
  • Mais le noyau hôte et le VMM peuvent toujours voir la mémoire de l’invité. Je ne le recommanderais pas pour cet usage
• Pour information, ce fork de Redox est entièrement basé sur Rust et ne contient aucun Makefile
• Beau travail ! Actuellement, FreeBSD 15 ne fait pas du tout fonctionner X dans UTM
  On en est réduit à RDP/VNC, donc j’espère que cette amélioration permettra aussi de faire fonctionner le framebuffer