OpenBSD-current kann jetzt als Gast auf Apple Hypervisor ausgeführt werden

• OpenBSD/arm64 kann nun in einer Apple-Hypervisor-Umgebung als Gastbetriebssystem laufen
• Durch eine Reihe von Commits wurden Grafikverarbeitung und Netzwerkfunktionen korrigiert und verbessert, wodurch Kernel-Panics und das X11-Black-Screen-Problem behoben wurden
• Es funktioniert jetzt vollständig in der Apple-Virtualization-Umgebung und ist auf aktuellen Apple-Silicon-Macs nutzbar

---

Unterstützung für OpenBSD/arm64 auf Apple Hypervisor

• Durch aktuelle Commits kann OpenBSD/arm64 nun als Gastbetriebssystem auf dem Apple Hypervisor ausgeführt werden
  • Die entsprechenden Commits stammen von Helg Bredow(helg@) und Stefan Fritsch(sf@)

Helg Bredows viogpu-Fix

• In der Datei sys/dev/pv/viogpu.c wurde die Funktion viogpu_wsmmap() angepasst
  • Zuvor wurde eine virtuelle Kernel-Adresse (kva) zurückgegeben, jetzt wird über bus_dmamem_mmap(9) eine physische Adresse zurückgegeben
  • Dieser Fix behebt das Black-Screen-Problem beim Ausführen von X11 in QEMU sowie Kernel-Panics auf Apple Hypervisor
• Vor dem Übertragen des Framebuffers in den Host-Speicher wurde ein Aufruf von bus_dmamap_sync(9) ergänzt
  • Dadurch kann der auf einer anderen CPU laufende Host Aktualisierungen des Framebuffers erkennen
  • Review und Feedback zu der Änderung kamen von kettenis@, das ok wurde von sf@ erteilt

Stefan Fritschs virtio-Netzwerk-Fix

• In der Datei sys/dev/pv/if_vio.c wurde Unterstützung für das Feature VIRTIO_NET_F_MTU hinzugefügt
  • Der hardmtu-Wert wird vom Hypervisor übernommen und die aktuelle MTU entsprechend gesetzt
  • Obwohl der virtio-Standard hier nicht eindeutig ist, wurde derselbe Ansatz wie unter Linux gewählt
• ETHER_MAX_HARDMTU_LEN wird als Obergrenze verwendet und ermöglicht damit eine genauere Behandlung als das bisherige MAXMCLBYTES
  • Falls der Hypervisor eine größere MTU anfordert, wird ohne das Feature VIRTIO_NET_F_MTU neu verhandelt
• Mit diesem Commit funktioniert OpenBSD vollständig in der Apple-Virtualization-Umgebung
  • Input und Tests kamen von helg@, das ok wurde von jan@ erteilt

Hinweise für Nutzer und Testempfehlung

• Diese Änderung ist besonders nützlich für Nutzer aktueller Apple-Silicon-Mac-Modelle
• Derzeit kann sie in der Snapshot-Version getestet werden; Feedback von Nutzern ist erwünscht

[GN⁺]

Hacker-News-Kommentare

• Gutes Update. Die VIRTIO_NET_F_MTU-Aushandlung war ein Hindernis für mehrere Gast-OS-Implementierungen im Apple-Virtualisierungs-Stack.
  Die Spezifikation ist mehrdeutig, daher funktioniert Linux einfach so, aber OpenBSD musste einen separaten Patch einbauen, um harte MTU-Beschränkungen zu behandeln.
  Dank der Single-Thread-Leistung der M4/M5-Chips sind OpenBSD-Gäste eine ideale Umgebung zum Testen von pf-Konfigurationen oder zum Betreiben isolierter Mail-Server.
  Jetzt kann viogpu zuverlässig genutzt werden, sodass man bei schnellen VM-Installationen nicht mehr nur auf die serielle Konsole angewiesen ist.
  Großer Applaus für Helg und Stefan.
  • Ein Unikernel wäre vielleicht noch besser. Dann bräuchte man allerdings einen Unikernel für einen Mail-Server, der ohne OS laufen kann.
  • Ich brauche so eine grafische Umgebung nicht. Mein IaC (Infrastructure as Code) will beim Hochfahren von VMs keinerlei Interaktion.
• Die größere Nachricht ist, dass dieses Update einen QEMU-Kompatibilitätsfehler behoben hat.
  Wegen dieses Fehlers blieb OpenBSD auf arm64 beim Start von X hängen; das Problem war nach den Framebuffer-Änderungen in Version 7.3 entstanden.
  Die einzige Lösung war bisher, den Kernel-Treiber zu deaktivieren, aber jetzt können wohl mehr Leute OpenBSD problemlos ausprobieren.
  • Ich bin einer davon. Ich wollte es schon länger ausprobieren, konnte aber nicht, weil meine einzige Maschine ein MacBook Pro ist.
  • Ich frage mich, warum QEMU X starten sollte. Ist das nicht eher Aufgabe von OpenBSD?
• Hier geht es um Virtualization.framework (Apples First-Party-VMM).
  OpenBSD lief schon seit Langem auch mit der Kombination Hypervisor.framework + QEMU.
  • Die Namen sind viel zu verwirrend. Die beiden Frameworks auseinanderzuhalten ist fast unmöglich.
  • Ich weiß es nicht genau, aber wurde das mit Tahoe eingeführt? Ich frage mich, warum damit etwas gelöst wurde, was vorher nicht möglich war.
  • Ich war auch verwirrt. UTM nutzt intern QEMU, aber jetzt bootet ein OpenBSD-Snapshot in QEMU problemlos. Es läuft allerdings immer noch virtualisiert.
• Vielleicht habe ich etwas übersehen, aber beim Testen von VMs gab es ein Problem, bei dem der Speicher, wenn er einmal gewachsen war, nie wieder kleiner wurde.
  Falls das ein echtes Thema ist, würde mich interessieren, ob es da Verbesserungen gibt.
  • Dass ein Gast dem Host mitteilt: „Diesen Speicher habe ich vollständig freigegeben, du kannst ihn zurückholen“, ist ziemlich kompliziert.
    Umgekehrt ist es viel einfacher, wenn der Gast glaubt, er habe 4 GiB RAM, der Host aber tatsächlich nur beim Zugriff Speicher zuweist.
    VMs sind etwas völlig anderes als Container.
  • Mich würde interessieren, wo du die VM getestet hast. Weltweit laufen jeden Tag Hunderte Millionen VMs.
• Gibt es dafür eine Anleitung, um das selbst auszuprobieren? Ich habe noch nie einen rohen Hypervisor benutzt.
  • Mit einer schnellen Kagi-Suche habe ich diesen Blogbeitrag gefunden. Vielleicht hilft er.
  • Im Grunde erstellt man den Kernel und bei Bedarf eine RAM-Disk und bootet dann wie bei Linux.
• Etwas am Rande, aber UTM Remote ist ein wirklich großartiger Remote-Client für VMs.
  Ich wünschte, er würde auch andere Hypervisor-Protokolle unterstützen (libvirtd, bhyve usw.).
• Ich frage mich, ob OpenBSD, wenn es als Gast läuft, hinreichend sicher ist.
  Ich würde gern wissen, ob es so isoliert ist, dass selbst der Host mathematisch nicht eindringen kann. Für Schlüsselverwaltung könnte es ideal sein.
  • Stand 2025 unterstützt OpenBSD AMD SEV/SEV-ES, und SEV-SNP ist in Entwicklung.
    Mit passender Hardware ist also durchaus eine starke Isolation möglich.
    Behandelt wird das auch in diesem BSDCan-2025-Vortrag.
  • Aber Host-Kernel und VMM können den Gastspeicher weiterhin sehen. Für so einen Einsatzzweck würde ich es nicht empfehlen.
• Zur Info: dieser Redox-Fork ist vollständig Rust-basiert und hat überhaupt kein Makefile.
• Gut gemacht! Aktuell funktioniert unter FreeBSD 15 X in UTM überhaupt nicht.
  Im Moment geht nur RDP/VNC, daher hoffe ich, dass mit dieser Verbesserung auch der Framebuffer funktioniert.