OpenBSD-current, अब Apple Hypervisor में guest के रूप में चल सकता है

 (undeadly.org)
2 पॉइंट द्वारा GN⁺ 2026-01-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenBSD/arm64 अब Apple Hypervisor environment में guest operating system के रूप में चल सकता है
  • commits की एक श्रृंखला के ज़रिए graphics processing और network functionality को ठीक और बेहतर किया गया, जिससे kernel panic और X11 black screen समस्याएँ हल हुईं
  • अब यह Apple Virtualization environment में पूरी तरह काम करता है और नवीनतम Apple Silicon Mac पर इस्तेमाल किया जा सकता है

Apple Hypervisor में OpenBSD/arm64 support

  • हालिया commits के ज़रिए OpenBSD/arm64 अब Apple Hypervisor में guest operating system के रूप में चल सकता है
    • संबंधित commits Helg Bredow(helg@) और Stefan Fritsch(sf@) ने किए

Helg Bredow के viogpu fixes

  • sys/dev/pv/viogpu.c फ़ाइल में viogpu_wsmmap() function को संशोधित किया गया
    • पहले यह kernel virtual address (kva) लौटाता था, लेकिन अब bus_dmamem_mmap(9) के ज़रिए physical address लौटाता है
    • इस बदलाव से QEMU में X11 चलाते समय आने वाली black screen समस्या और Apple Hypervisor में होने वाला kernel panic हल हो गया
  • framebuffer को host memory में transfer करने से पहले bus_dmamap_sync(9) call जोड़ा गया
    • इससे दूसरे CPU पर चल रहा host framebuffer updates को पहचान सकता है
    • बदलाव की समीक्षा और feedback kettenis@ ने दिया, और approval(ok) sf@ ने दिया

Stefan Fritsch के virtio network fixes

  • sys/dev/pv/if_vio.c फ़ाइल में VIRTIO_NET_F_MTU feature support जोड़ा गया
    • hypervisor से hardmtu value लेकर current MTU को उसी के बराबर सेट किया जाता है
    • virtio standard पूरी तरह स्पष्ट नहीं है, लेकिन Linux के समान तरीका अपनाया गया है
  • ETHER_MAX_HARDMTU_LEN को upper bound के रूप में इस्तेमाल किया गया, जो पहले के MAXMCLBYTES से अधिक सटीक है
    • अगर hypervisor इससे बड़ा MTU माँगता है, तो VIRTIO_NET_F_MTU feature के बिना renegotiation किया जाता है
  • इस commit से OpenBSD Apple Virtualization environment में पूरी तरह काम करता है
    • input और testing helg@ ने की, और approval(ok) jan@ ने दिया

user guidance और testing recommendation

  • यह बदलाव नवीनतम Apple Silicon Mac models के उपयोगकर्ताओं के लिए खास तौर पर उपयोगी है
  • इसे अभी snapshot version में test किया जा सकता है, और users से feedback माँगा गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-17
Hacker News की टिप्पणियाँ
  • यह एक बढ़िया अपडेट है। VIRTIO_NET_F_MTU negotiation Apple virtualization stack में कई guest OS implementations के लिए रुकावट थी
    spec अस्पष्ट था, इसलिए Linux तो बस चल जाता था, लेकिन OpenBSD को hard MTU limit संभालने के लिए अलग patch लगाना पड़ता था
    M4/M5 chips की single-thread performance की वजह से OpenBSD guest, pf config testing या isolated mail server चलाने के लिए एक आदर्श environment है
    अब viogpu को स्थिर तरीके से इस्तेमाल किया जा सकता है, इसलिए तेज़ VM installation के समय केवल serial console इस्तेमाल करने वाले तरीके से बाहर निकला जा सकता है
    Helg और Stefan के लिए ज़ोरदार तालियाँ
    • unikernel हो to शायद और बेहतर हो। लेकिन उस स्थिति में mail server के लिए एक unikernel चाहिए होगा जो OS के बिना चल सके
    • मुझे ऐसे graphical environment की ज़रूरत नहीं है। मेरा IaC(infrastructure code) VM उठाते समय किसी भी interaction को नहीं चाहता
  • इससे भी बड़ी ख़बर यह है कि इस अपडेट ने QEMU compatibility bug को ठीक कर दिया
    इस bug की वजह से arm64 पर OpenBSD, X शुरू करते समय अटक जाता था, और यह 7.3 version के framebuffer बदलाव के बाद पैदा हुई समस्या थी
    एकमात्र समाधान kernel driver को disable करना था, लेकिन अब लगता है कि और लोग OpenBSD को बिना समस्या आज़मा सकेंगे
    • मैं भी उन्हीं में से एक हूँ। मैं कुछ समय से इसे इस्तेमाल करना चाहता था, लेकिन मेरी एकमात्र मशीन MacBook Pro है, इसलिए नहीं कर पाया
    • सोच रहा हूँ कि QEMU को X शुरू करने की ज़रूरत ही क्यों है। क्या वह OpenBSD का काम नहीं है?
  • यह Virtualization.framework (Apple का 1st-party VMM) के बारे में बात है
    OpenBSD बहुत पहले से Hypervisor.framework + QEMU के संयोजन में भी काम करता था
    • नाम इतने उलझाऊ हैं। दोनों frameworks में फ़र्क करना लगभग असंभव है
    • मुझे ठीक से पता नहीं, लेकिन क्या वह Tahoe में जोड़ा गया था? जानना चाहता हूँ कि ऐसा क्या बदला जिससे पहले असंभव चीज़ संभव हो गई
    • मैं भी भ्रमित था। UTM अंदर से QEMU का उपयोग करता है, लेकिन अब OpenBSD snapshot QEMU में बिना अड़चन boot हो जाता है। यह अभी भी virtualized ही है
  • हो सकता है मुझसे कुछ छूट रहा हो, लेकिन VM test करते समय एक समस्या थी कि memory एक बार बढ़ जाए तो फिर कभी कम नहीं होती
    अगर यह सचमुच एक issue है, तो जानना चाहूँगा कि इसमें कोई सुधार हुआ है या नहीं
    • guest का host को यह बताना कि “यह memory पूरी तरह free कर दी गई है, इसे वापस ले सकते हो” काफ़ी जटिल काम है
      इसके उलट guest का यह मानना कि उसके पास 4GiB RAM है, लेकिन वास्तव में host उसे केवल access के समय allocate करे, यह कहीं अधिक सरल है
      VM, container से पूरी तरह अलग चीज़ है
    • जानना चाहूँगा कि आपने VM कहाँ test किया। दुनिया भर में हर दिन करोड़ों VM चल रहे हैं
  • क्या इसे खुद करके देखने के लिए कोई guide है? मैंने कभी raw hypervisor इस्तेमाल नहीं किया
    • एक तेज़ Kagi search से मुझे यह ब्लॉग पोस्ट मिली। शायद यह मदद करे
    • मूल रूप से kernel और ज़रूरत पड़ने पर RAM disk बनाकर Linux की तरह boot करना होता है
  • थोड़ा संबंधित विषय है, लेकिन UTM Remote वाकई एक शानदार VM remote client है
    काश यह दूसरे hypervisor protocols (libvirtd, bhyve आदि) को भी support करे
  • जानना चाहता हूँ कि guest के रूप में चलते समय OpenBSD की security पर्याप्त है या नहीं
    मैं जानना चाहता हूँ कि क्या यह host से गणितीय रूप से भी घुसपैठ-असंभव स्तर तक isolate हो सकता है। key management के लिए यह आदर्श हो सकता है
    • 2025 तक OpenBSD, AMD SEV/SEV-ES को support करता है, और SEV-SNP development में है
      अगर आपके पास उपयुक्त hardware है, तो काफ़ी अच्छा isolation संभव है
      संबंधित विषय BSDCan 2025 presentation में भी कवर किया गया है
    • लेकिन host kernel और VMM अभी भी guest memory देख सकते हैं। ऐसे उपयोग के लिए मैं इसकी सिफ़ारिश नहीं करूँगा
  • संदर्भ के लिए, यह Redox fork पूरी तरह Rust-आधारित है और इसमें बिल्कुल भी Makefile नहीं है
  • बढ़िया काम! अभी FreeBSD 15 में UTM पर X बिल्कुल काम नहीं करता
    अभी केवल RDP/VNC ही संभव है, इसलिए उम्मीद है कि इस सुधार से framebuffer काम करने लगेगा