OpenBSD-current kini dapat berjalan sebagai tamu di Apple Hypervisor

• OpenBSD/arm64 kini dapat berjalan sebagai sistem operasi tamu di lingkungan Apple Hypervisor
• Melalui serangkaian commit, pemrosesan grafis dan fungsi jaringan diperbaiki dan ditingkatkan sehingga masalah kernel panic dan layar hitam pada X11 berhasil diatasi
• Kini berjalan sepenuhnya di lingkungan Apple Virtualization dan dapat digunakan pada Apple Silicon Mac terbaru

---

Dukungan OpenBSD/arm64 di Apple Hypervisor

• Melalui commit terbaru, OpenBSD/arm64 kini dapat dijalankan sebagai sistem operasi tamu di Apple Hypervisor
  • Commit terkait dikerjakan oleh Helg Bredow(helg@) dan Stefan Fritsch(sf@)

Perbaikan viogpu oleh Helg Bredow

• Fungsi viogpu_wsmmap() di file sys/dev/pv/viogpu.c telah diperbaiki
  • Sebelumnya mengembalikan alamat virtual kernel (kva), tetapi kini mengembalikan alamat fisik melalui bus_dmamem_mmap(9)
  • Perbaikan ini menyelesaikan masalah layar hitam saat menjalankan X11 di QEMU dan kernel panic di Apple Hypervisor
• Penambahan pemanggilan bus_dmamap_sync(9) sebelum framebuffer dikirim ke memori host
  • Dengan ini, host yang berjalan di CPU lain dapat mengenali pembaruan framebuffer
  • Tinjauan dan masukan untuk perbaikan ini dilakukan oleh kettenis@, dan persetujuan (ok) diberikan oleh sf@

Perbaikan jaringan virtio oleh Stefan Fritsch

• Penambahan dukungan untuk fitur VIRTIO_NET_F_MTU di file sys/dev/pv/if_vio.c
  • Mengambil nilai hardmtu dari hypervisor dan menetapkan MTU saat ini ke nilai yang sama
  • Meski standar virtio tidak sepenuhnya jelas, pendekatan yang dipakai sama seperti Linux
• Menggunakan ETHER_MAX_HARDMTU_LEN sebagai batas atas sehingga penanganannya lebih akurat dibanding MAXMCLBYTES sebelumnya
  • Jika hypervisor meminta MTU yang lebih besar dari ini, akan dilakukan negosiasi ulang tanpa fitur VIRTIO_NET_F_MTU
• Dengan commit ini, OpenBSD kini berfungsi sepenuhnya di lingkungan Apple Virtualization
  • Masukan dan pengujian dilakukan oleh helg@, dan persetujuan (ok) diberikan oleh jan@

Panduan pengguna dan anjuran pengujian

• Perubahan ini sangat berguna terutama bagi pengguna Apple Silicon Mac model terbaru
• Saat ini dapat diuji pada versi snapshot, dan umpan balik dari pengguna diminta

[GN⁺]

Komentar Hacker News

• Pembaruan yang bagus. Negosiasi VIRTIO_NET_F_MTU selama ini menjadi kendala bagi implementasi berbagai OS tamu di stack virtualisasi Apple
  Karena spesifikasinya ambigu, Linux tetap berjalan begitu saja, tetapi OpenBSD harus menambahkan patch terpisah untuk menangani batas MTU keras
  Berkat performa single-thread chip M4/M5, tamu OpenBSD menjadi lingkungan yang ideal untuk menguji konfigurasi pf atau menjalankan server mail yang terisolasi
  Sekarang viogpu juga bisa dipakai dengan stabil, jadi saat memasang VM dengan cepat kita tidak lagi harus hanya mengandalkan konsol serial
  Tepuk tangan besar untuk Helg dan Stefan
  • Mungkin akan lebih baik lagi kalau pakai unikernel. Hanya saja, dalam kasus itu dibutuhkan unikernel untuk server mail yang bisa berjalan tanpa OS
  • Saya tidak butuh lingkungan grafis seperti itu. IaC (infrastructure as code) saya tidak menginginkan interaksi apa pun saat menyalakan VM
• Kabar yang lebih besar adalah pembaruan ini memperbaiki bug kompatibilitas QEMU
  Karena bug ini, OpenBSD di arm64 sempat macet saat memulai X, dan masalah ini muncul setelah perubahan framebuffer pada versi 7.3
  Satu-satunya solusi sebelumnya adalah menonaktifkan driver kernel, tetapi sekarang sepertinya lebih banyak orang bisa mencoba OpenBSD tanpa kendala
  • Saya juga salah satunya. Sudah lama ingin mencobanya, tetapi satu-satunya mesin saya adalah MacBook Pro jadi tidak bisa
  • Saya penasaran kenapa QEMU harus memulai X. Bukankah itu tugas OpenBSD?
• Ini tentang Virtualization.framework (VMM pihak pertama milik Apple)
  OpenBSD sebenarnya sudah lama bisa berjalan dengan kombinasi Hypervisor.framework + QEMU
  • Namanya terlalu membingungkan. Membedakan dua framework itu nyaris mustahil
  • Saya kurang tahu, tapi apakah itu diperkenalkan di Tahoe? Saya penasaran kenapa sekarang bisa menyelesaikan hal yang sebelumnya tidak bisa
  • Saya juga sempat bingung. UTM memakai QEMU di dalamnya, tetapi sekarang snapshot OpenBSD bisa boot dengan mulus di QEMU. Tetap dalam keadaan tervirtualisasi tentunya
• Mungkin saya melewatkan sesuatu, tetapi saat menguji VM ada masalah di mana begitu memori membesar, ukurannya tidak pernah mengecil lagi
  Kalau ini memang isu nyata, saya penasaran apakah ada perbaikannya
  • Cukup rumit bagi tamu untuk memberi tahu host bahwa “memori ini sudah benar-benar dibebaskan, jadi boleh direklamasi”
    Sebaliknya, jauh lebih sederhana bila tamu percaya bahwa ia punya RAM 4GiB, tetapi host baru mengalokasikannya saat benar-benar diakses
    VM adalah entitas yang sepenuhnya berbeda dari container
  • Saya penasaran Anda menguji VM di mana. Ada ratusan juta VM yang berjalan setiap hari di seluruh dunia
• Apakah ada panduan untuk mencoba ini sendiri? Saya belum pernah memakai hypervisor mentah
  • Dengan pencarian cepat di Kagi saya menemukan posting blog ini. Mungkin bisa membantu
  • Pada dasarnya cukup buat kernel dan, jika perlu, RAM disk, lalu boot seperti Linux
• Sedikit terkait, tetapi UTM Remote benar-benar klien remote VM yang luar biasa
  Saya berharap ia juga mendukung protokol hypervisor lain (libvirtd, bhyve, dll.)
• Saya penasaran apakah OpenBSD cukup aman saat dijalankan sebagai tamu
  Saya ingin tahu apakah ia terisolasi sampai host secara matematis tidak bisa menyusup. Mungkin ideal untuk pengelolaan kunci
  • Per 2025, OpenBSD mendukung AMD SEV/SEV-ES, dan SEV-SNP sedang dikembangkan
    Dengan hardware yang sesuai, isolasi yang memadai memungkinkan
    Hal terkait ini juga dibahas dalam presentasi BSDCan 2025
  • Tetapi kernel host dan VMM masih bisa melihat memori tamu. Saya tidak merekomendasikannya untuk tujuan seperti itu
• Sebagai referensi, fork Redox ini sepenuhnya berbasis Rust dan sama sekali tidak memiliki Makefile
• Bagus sekali! Saat ini FreeBSD 15 di UTM sama sekali tidak bisa menjalankan X
  Hanya RDP/VNC yang memungkinkan, jadi saya berharap perbaikan ini memungkinkan framebuffer berfungsi