OpenBSD-current artık Apple Hypervisor üzerinde misafir olarak çalışabiliyor

• OpenBSD/arm64, Apple Hypervisor ortamında misafir işletim sistemi olarak çalışabilir hale geldi
• Bir dizi commit ile grafik işleme ve ağ işlevleri düzeltilip iyileştirildi; böylece kernel panic ve X11 siyah ekran sorunları çözüldü
• Artık Apple Virtualization ortamında tamamen çalışıyor ve en yeni Apple Silicon Mac modellerinde kullanılabiliyor

---

Apple Hypervisor'da OpenBSD/arm64 desteği

• Son commit'lerle OpenBSD/arm64, Apple Hypervisor üzerinde misafir işletim sistemi olarak çalıştırılabiliyor
  • İlgili commit'ler Helg Bredow(helg@) ve Stefan Fritsch(sf@) tarafından yapıldı

Helg Bredow'un viogpu düzeltmeleri

• sys/dev/pv/viogpu.c dosyasında viogpu_wsmmap() fonksiyonu değiştirildi
  • Önceden kernel sanal adresi (kva) döndürürken, artık bus_dmamem_mmap(9) üzerinden fiziksel adres döndürüyor
  • Bu düzeltmeyle QEMU'da X11 çalıştırılırken görülen siyah ekran sorunu ve Apple Hypervisor üzerindeki kernel panic çözüldü
• Framebuffer'ı host belleğine aktarmadan önce bus_dmamap_sync(9) çağrısı eklendi
  • Böylece başka bir CPU üzerinde çalışan host, framebuffer güncellemelerini fark edebiliyor
  • Düzeltmenin incelemesi ve geri bildirimi kettenis@ tarafından yapıldı, onay (ok) sf@ tarafından verildi

Stefan Fritsch'in virtio ağ düzeltmeleri

• sys/dev/pv/if_vio.c dosyasında VIRTIO_NET_F_MTU özelliği desteği eklendi
  • Hypervisor'dan hardmtu değeri alınarak mevcut MTU buna eşit olacak şekilde ayarlanıyor
  • virtio standardı net olmamakla birlikte, Linux ile aynı yaklaşım benimsendi
• Üst sınır olarak ETHER_MAX_HARDMTU_LEN kullanılarak önceki MAXMCLBYTES yaklaşımına göre daha doğru bir işlem sağlandı
  • Hypervisor bunun üstünde bir MTU isterse, VIRTIO_NET_F_MTU özelliği olmadan yeniden müzakere yapılıyor
• Bu commit ile OpenBSD, Apple Virtualization ortamında tamamen çalışır hale geldi
  • Girdi ve testler helg@ tarafından sağlandı, onay (ok) jan@ tarafından verildi

Kullanıcı bilgilendirmesi ve test önerisi

• Bu değişiklik özellikle en yeni Apple Silicon Mac modellerini kullananlar için faydalı
• Şu anda snapshot sürümünde test edilebiliyor ve kullanıcılardan geri bildirim isteniyor

[GN⁺]

Hacker News yorumları

• Güzel bir güncelleme. VIRTIO_NET_F_MTU anlaşması, Apple sanallaştırma yığınında birden fazla konuk işletim sistemi uygulaması için engeldi
  Spesifikasyon belirsiz olduğu için Linux sadece çalışıyor, ama OpenBSD’nin katı MTU sınırını ele almak için ayrı bir yama eklemesi gerekiyordu
  M4/M5 çiplerinin tek iş parçacıklı performansı sayesinde OpenBSD konuğu, pf yapılandırma testi ya da izole bir posta sunucusu çalıştırmak için ideal bir ortam
  Artık viogpu güvenilir şekilde kullanılabildiği için, hızlı VM kurulumu sırasında yalnızca seri konsol kullanma yönteminden çıkılabiliyor
  Helg ve Stefan’a büyük alkış
  • Bir unikernel olsaydı daha da iyi olabilirdi. Ama o durumda, işletim sistemi olmadan çalışabilen posta sunucusu için bir unikernel gerekirdi
  • Benim böyle bir grafik ortamına ihtiyacım yok. IaC (altyapıyı kod olarak yönetme) düzenim, VM ayağa kalkarken hiçbir etkileşim istemiyor
• Daha büyük haber, bu güncellemenin QEMU uyumluluk hatasını çözmüş olması
  Bu hata yüzünden OpenBSD arm64 üzerinde X başlatırken takılıyordu; sorun 7.3 sürümündeki framebuffer değişikliğinden sonra ortaya çıkmıştı
  Tek çözüm çekirdek sürücüsünü devre dışı bırakmaktı, ama artık daha fazla kişi OpenBSD’yi sorunsuz deneyebilecek gibi görünüyor
  • Ben de onlardan biriyim. Bir süredir denemek istiyordum ama elimdeki tek makine MacBook Pro olduğu için yapamıyordum
  • QEMU’nun neden X’i başlatması gerektiğini merak ediyorum. Bu OpenBSD’nin görevi değil mi?
• Bu, Virtualization.framework’e (Apple’ın 1st-party VMM’i) dair bir konu
  OpenBSD uzun zamandır Hypervisor.framework + QEMU kombinasyonunda da çalışıyordu
  • İsimler fazla kafa karıştırıcı. İki framework’ü ayırt etmek neredeyse imkansız
  • Tam bilmiyorum ama bu Tahoe ile mi gelmişti? Daha önce mümkün olmayan şeyi neyin çözdüğünü merak ediyorum
  • Ben de karıştırdım. UTM içeride QEMU kullanıyor, ama artık OpenBSD snapshot’ı QEMU’da sorunsuz açılıyor. Hâlâ sanallaştırılmış durumda tabii
• Bir şeyi kaçırıyor olabilirim ama VM test ederken belleğin bir kez büyüdükten sonra asla geri küçülmemesi gibi bir sorun vardı
  Bu gerçekten bir sorunsa, bir iyileştirme olup olmadığını merak ediyorum
  • Konuğun ana makineye “bu belleği tamamen bıraktım, geri alabilirsin” demesi oldukça karmaşık bir iş
    Buna karşılık, konuğun 4GiB RAM’i olduğuna inanması ama aslında ana makinenin yalnızca erişildiğinde tahsis yapması çok daha basit
    VM’ler konteynerlerden tamamen farklı bir şeydir
  • VM’yi nerede test ettiğini merak ediyorum. Dünya genelinde her gün yüz milyonlarca VM çalışıyor
• Bunu bizzat denemek için bir rehber var mı? Daha önce hiç ham hypervisor kullanmadım
  • Hızlı bir Kagi aramasıyla şu blog yazısını buldum. Belki yardımcı olabilir
  • Temelde çekirdeği ve gerekirse RAM diskini oluşturup Linux gibi önyüklüyorsun
• Biraz ilişkili bir konu ama UTM Remote gerçekten harika bir VM uzak istemcisi
  Keşke diğer hypervisor protokollerini de (libvirtd, bhyve vb.) desteklese
• OpenBSD konuk olarak çalıştığında güvenliğinin yeterince güçlü olup olmadığını merak ediyorum
  Ana makineden matematiksel olarak sızılması imkansız olacak kadar yalıtılıp yalıtılmadığını bilmek isterim. Anahtar yönetimi için ideal olabilir
  • 2025 itibarıyla OpenBSD, AMD SEV/SEV-ES destekliyor ve SEV-SNP geliştiriliyor
    Uygun donanım varsa yeterince iyi yalıtım mümkün
    İlgili konu BSDCan 2025 sunumunda da ele alınıyor
  • Ama ana makine çekirdeği ve VMM hâlâ konuk belleğini görebilir. Böyle bir kullanım için tavsiye etmem
• Bilgi olsun diye, bu Redox fork’u tamamen Rust tabanlı ve hiç Makefile içermiyor
• Eline sağlık! Şu anda FreeBSD 15’te UTM içinde X hiç çalışmıyor
  Yalnızca RDP/VNC kullanılabiliyor; bu iyileştirmeyle framebuffer’ın çalışmasını umuyorum