OpenBSD-current ตอนนี้สามารถรันเป็น guest บน Apple Hypervisor ได้แล้ว

 (undeadly.org)
2 คะแนน โดย GN⁺ 2026-01-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenBSD/arm64 สามารถทำงานเป็นระบบปฏิบัติการ guest บนสภาพแวดล้อม Apple Hypervisor ได้แล้ว
  • ผ่านชุดคอมมิตที่แก้ไขและปรับปรุง การประมวลผลกราฟิกและความสามารถด้านเครือข่าย จึงแก้ปัญหา kernel panic และปัญหาหน้าจอดำของ X11 ได้
  • ตอนนี้ทำงานได้อย่างสมบูรณ์ในสภาพแวดล้อม Apple Virtualization และใช้งานได้บน Apple Silicon Mac รุ่นล่าสุด

การรองรับ OpenBSD/arm64 บน Apple Hypervisor

  • จากคอมมิตล่าสุด ทำให้ OpenBSD/arm64 สามารถรันเป็นระบบปฏิบัติการ guest บน Apple Hypervisor ได้
    • คอมมิตที่เกี่ยวข้องดำเนินการโดย Helg Bredow(helg@) และ Stefan Fritsch(sf@)

การแก้ไข viogpu ของ Helg Bredow

  • มีการแก้ไขฟังก์ชัน viogpu_wsmmap() ในไฟล์ sys/dev/pv/viogpu.c
    • เดิมทีฟังก์ชันนี้คืนค่า kernel virtual address (kva) แต่ตอนนี้คืนค่า physical address ผ่าน bus_dmamem_mmap(9)
    • การแก้ไขนี้ช่วยแก้ ปัญหาหน้าจอดำ ตอนรัน X11 บน QEMU และ kernel panic บน Apple Hypervisor
  • เพิ่มการเรียก bus_dmamap_sync(9) ก่อนส่งเฟรมบัฟเฟอร์ไปยังหน่วยความจำของโฮสต์
    • ทำให้โฮสต์ที่กำลังรันอยู่บน CPU อื่นสามารถรับรู้การอัปเดตของเฟรมบัฟเฟอร์ได้
    • kettenis@ เป็นผู้ตรวจทานและให้ข้อเสนอแนะ ส่วนการอนุมัติ (ok) มาจาก sf@

การแก้ไขเครือข่าย virtio ของ Stefan Fritsch

  • เพิ่มการรองรับ VIRTIO_NET_F_MTU ในไฟล์ sys/dev/pv/if_vio.c
    • ดึงค่า hardmtu จากไฮเปอร์ไวเซอร์ แล้วตั้งค่า MTU ปัจจุบันให้เท่ากัน
    • แม้มาตรฐาน virtio จะไม่ชัดเจนนัก แต่เลือกใช้ แนวทางเดียวกับ Linux
  • ใช้ ETHER_MAX_HARDMTU_LEN เป็นค่าขีดจำกัดบน ซึ่งแม่นยำกว่าการใช้ MAXMCLBYTES แบบเดิม
    • หากไฮเปอร์ไวเซอร์ร้องขอ MTU ที่ใหญ่กว่านี้ จะทำ การเจรจาใหม่โดยไม่ใช้ความสามารถ VIRTIO_NET_F_MTU
  • คอมมิตนี้ทำให้ OpenBSD ทำงานได้อย่างสมบูรณ์ในสภาพแวดล้อม Apple Virtualization
    • helg@ เป็นผู้ให้ข้อมูลและทดสอบ ส่วนการอนุมัติ (ok) มาจาก jan@

คำแนะนำสำหรับผู้ใช้และการทดสอบ

  • การเปลี่ยนแปลงนี้มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ Apple Silicon Mac รุ่นล่าสุด
  • ขณะนี้สามารถทดสอบได้ใน เวอร์ชัน snapshot และมีการขอความคิดเห็นจากผู้ใช้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-17
ความคิดเห็นบน Hacker News
  • เป็นอัปเดตที่ดีมาก การเจรจา VIRTIO_NET_F_MTU เป็นอุปสรรคของการรองรับ guest OS หลายตัวบนสแตก virtualization ของ Apple มาโดยตลอด
    เพราะสเปกกำกวม Linux เลยใช้งานได้เลย แต่ OpenBSD ต้องใส่แพตช์แยกเพื่อจัดการข้อจำกัด MTU แบบตายตัว
    ด้วยประสิทธิภาพ single-thread ของชิป M4/M5 ทำให้ OpenBSD guest เหมาะมากสำหรับการทดสอบการตั้งค่า pf หรือรันเมลเซิร์ฟเวอร์แบบแยกขาด
    ตอนนี้สามารถใช้ viogpu ได้อย่างเสถียรแล้ว จึงไม่จำเป็นต้องพึ่งแค่ serial console เวลาติดตั้ง VM แบบรวดเร็วอีกต่อไป
    ขอปรบมือดัง ๆ ให้ Helg และ Stefan
    • ถ้าเป็น unikernel อาจจะดีกว่าอีก แต่ในกรณีนั้นก็ต้องมี unikernel สำหรับเมลเซิร์ฟเวอร์ ที่ทำงานได้โดยไม่ต้องมี OS
    • ฉันไม่ต้องการสภาพแวดล้อมแบบกราฟิกนั้น IaC (Infrastructure as Code) ของฉันไม่ควรต้องการการโต้ตอบใด ๆ ตอนบูต VM
  • ข่าวที่ใหญ่กว่าคืออัปเดตนี้แก้ บั๊กความเข้ากันได้กับ QEMU
    บั๊กนี้ทำให้ OpenBSD ค้างตอนเริ่ม X บน arm64 และเป็นปัญหาที่เกิดขึ้นหลังการเปลี่ยนแปลงเฟรมบัฟเฟอร์ในเวอร์ชัน 7.3
    ทางแก้เดียวก่อนหน้านี้คือปิดไดรเวอร์เคอร์เนล แต่ตอนนี้น่าจะมีคนลองใช้ OpenBSD ได้แบบไม่มีปัญหามากขึ้น
    • ฉันก็เป็นหนึ่งในนั้น อยากลองใช้มาสักพักแล้ว แต่มีแค่ MacBook Pro เครื่องเดียวเลยทำไม่ได้
    • สงสัยว่าเหตุใด QEMU ถึงต้องเป็นฝ่ายเริ่ม X ฟังดูเหมือนนั่นควรเป็นหน้าที่ของ OpenBSD มากกว่า
  • นี่เป็นเรื่องเกี่ยวกับ Virtualization.framework (VMM ของ Apple เอง)
    OpenBSD ใช้งานได้กับชุด Hypervisor.framework + QEMU มานานแล้ว
    • ชื่อทำให้สับสนมาก แทบจะแยกสองเฟรมเวิร์กนี้ไม่ออก
    • ไม่แน่ใจว่าอันนี้ถูกเพิ่มเข้ามาใน Tahoe หรือเปล่า เลยสงสัยว่าทำไมสิ่งที่ก่อนหน้านี้ทำไม่ได้ถึงทำได้แล้ว
    • ฉันก็งงเหมือนกัน UTM ใช้ QEMU ภายใน แต่ตอนนี้ OpenBSD snapshot บูตบน QEMU ได้ลื่นไหลแล้ว ถึงอย่างนั้นก็ยังคงเป็นการ virtualization อยู่
  • อาจเป็นไปได้ว่าฉันพลาดอะไรไป แต่ตอนทดสอบ VM เคยเจอปัญหาว่าพอหน่วยความจำโตขึ้นแล้วมันจะ ไม่ลดลงอีกเลย
    ถ้านี่เป็นปัญหาจริงก็อยากรู้ว่ามีการปรับปรุงหรือยัง
    • การให้ guest แจ้ง host ว่า “หน่วยความจำส่วนนี้ถูกปล่อยทิ้งทั้งหมดแล้ว จะเก็บคืนไปก็ได้” เป็นเรื่องที่ค่อนข้างซับซ้อน
      ในทางกลับกัน การที่ guest เชื่อว่าตัวเองมี RAM 4GiB แต่จริง ๆ แล้ว host ค่อยจัดสรรเมื่อมีการเข้าถึงนั้นง่ายกว่ามาก
      VM เป็นสิ่งที่ต่างจากคอนเทนเนอร์โดยสิ้นเชิง
    • อยากรู้ว่าคุณทดสอบ VM ที่ไหน ทุกวันนี้มี VM หลายร้อยล้านตัวรันอยู่ทุกวันทั่วโลก
  • มี ไกด์ สำหรับลองทำเองไหม? ฉันไม่เคยใช้ raw hypervisor มาก่อน
    • ค้น Kagi แบบเร็ว ๆ แล้วเจอโพสต์บล็อกนี้ น่าจะช่วยได้
    • โดยพื้นฐานก็แค่สร้างเคอร์เนลและ RAM disk ถ้าจำเป็น แล้วบูตเหมือน Linux
  • เป็นเรื่องที่เกี่ยวข้องกันเล็กน้อย แต่ UTM Remote เป็นไคลเอนต์รีโมตสำหรับ VM ที่ยอดเยี่ยมจริง ๆ
    อยากให้รองรับโปรโตคอลของไฮเปอร์ไวเซอร์ตัวอื่นด้วย (เช่น libvirtd, bhyve)
  • สงสัยว่าเมื่อ OpenBSD รันเป็น guest แล้ว ความปลอดภัย ดีพอไหม
    อยากรู้ว่ามันแยกจาก host ได้ถึงขั้นที่ host ไม่สามารถเจาะเข้าไปได้ในเชิงคณิตศาสตร์หรือไม่ น่าจะเหมาะกับการจัดการคีย์มาก
    • ณ ปี 2025 OpenBSD รองรับ AMD SEV/SEV-ES แล้ว และ SEV-SNP กำลังพัฒนาอยู่
      ถ้ามีฮาร์ดแวร์ที่เหมาะสมก็สามารถแยกได้ดีพอสมควร
      มีพูดถึงเรื่องนี้ในงานนำเสนอ BSDCan 2025 ด้วย
    • แต่โฮสต์เคอร์เนลและ VMM ก็ยังสามารถเห็นหน่วยความจำของ guest ได้อยู่ ดังนั้นไม่แนะนำสำหรับการใช้งานแบบนั้น
  • เผื่อเป็นประโยชน์ fork ของ Redox นี้ เป็น Rust ล้วน และไม่มี Makefile เลย
  • เยี่ยมมาก! ตอนนี้ FreeBSD 15 บน UTM ยังทำให้ X ใช้งานไม่ได้เลย
    ใช้ได้แค่ RDP/VNC เท่านั้น หวังว่าการปรับปรุงครั้งนี้จะทำให้เฟรมบัฟเฟอร์ใช้งานได้