OpenBSD-current giờ đã có thể chạy như máy khách trên Apple Hypervisor

• OpenBSD/arm64 nay có thể hoạt động như hệ điều hành khách trong môi trường Apple Hypervisor
• Thông qua một loạt commit, xử lý đồ họa và chức năng mạng đã được sửa và cải thiện, giải quyết lỗi kernel panic và vấn đề màn hình đen của X11
• Giờ đây hệ thống hoạt động đầy đủ trong môi trường Apple Virtualization và có thể dùng trên các máy Apple Silicon Mac mới nhất

---

Hỗ trợ OpenBSD/arm64 trên Apple Hypervisor

• Qua các commit gần đây, OpenBSD/arm64 giờ có thể chạy như hệ điều hành khách trên Apple Hypervisor
  • Các commit liên quan được thực hiện bởi Helg Bredow(helg@) và Stefan Fritsch(sf@)

Bản sửa viogpu của Helg Bredow

• Trong tệp sys/dev/pv/viogpu.c, hàm viogpu_wsmmap() đã được chỉnh sửa
  • Trước đây hàm trả về địa chỉ ảo của kernel (kva), nhưng giờ trả về địa chỉ vật lý thông qua bus_dmamem_mmap(9)
  • Bản sửa này giải quyết vấn đề màn hình đen khi chạy X11 trên QEMU và kernel panic trên Apple Hypervisor
• Đã bổ sung lời gọi bus_dmamap_sync(9) trước khi truyền framebuffer sang bộ nhớ máy chủ
  • Nhờ đó, máy chủ đang chạy trên CPU khác có thể nhận biết các cập nhật framebuffer
  • Việc rà soát và phản hồi cho bản sửa do kettenis@ thực hiện, phê duyệt (ok) do sf@ cấp

Bản sửa mạng virtio của Stefan Fritsch

• Trong tệp sys/dev/pv/if_vio.c, đã bổ sung hỗ trợ cho tính năng VIRTIO_NET_F_MTU
  • Lấy giá trị hardmtu từ hypervisor và đặt MTU hiện tại giống với giá trị đó
  • Dù tiêu chuẩn virtio chưa thật sự rõ ràng, cách làm giống Linux đã được áp dụng
• Dùng ETHER_MAX_HARDMTU_LEN làm giới hạn trên, cho cách xử lý chính xác hơn MAXMCLBYTES trước đây
  • Nếu hypervisor yêu cầu MTU lớn hơn mức này, sẽ đàm phán lại mà không dùng tính năng VIRTIO_NET_F_MTU
• Với commit này, OpenBSD hoạt động hoàn chỉnh trong môi trường Apple Virtualization
  • Phần input và kiểm thử do helg@ thực hiện, phê duyệt (ok) do jan@ cấp

Hướng dẫn cho người dùng và khuyến nghị thử nghiệm

• Thay đổi này đặc biệt hữu ích với người dùng các mẫu Apple Silicon Mac mới nhất
• Hiện có thể thử nghiệm trên phiên bản snapshot, và nhóm phát triển đang mong nhận được phản hồi từ người dùng

[GN⁺]

Ý kiến trên Hacker News

• Đây là một bản cập nhật rất tốt. Đàm phán VIRTIO_NET_F_MTU đã là nút thắt trong nhiều triển khai hệ điều hành khách trên ngăn xếp ảo hóa của Apple
  Đặc tả khá mơ hồ nên Linux thì cứ thế hoạt động, nhưng OpenBSD phải thêm bản vá riêng để xử lý giới hạn MTU cứng
  Nhờ hiệu năng đơn luồng của chip M4/M5, máy khách OpenBSD là môi trường tối ưu để thử nghiệm cấu hình pf hoặc chạy máy chủ mail cô lập
  Giờ đây có thể dùng viogpu một cách ổn định, nên không còn phải chỉ dùng console nối tiếp khi cài VM nhanh nữa
  Xin dành một tràng pháo tay lớn cho Helg và Stefan
  • Có lẽ unikernel sẽ còn tốt hơn. Nhưng trong trường hợp đó sẽ cần một unikernel cho máy chủ mail có thể chạy mà không cần hệ điều hành
  • Tôi không cần môi trường đồ họa như vậy. IaC (hạ tầng dưới dạng mã) của tôi không muốn bất kỳ tương tác nào khi khởi chạy VM
• Tin lớn hơn là bản cập nhật này đã sửa một lỗi tương thích QEMU
  Lỗi này khiến OpenBSD bị treo khi khởi động X trên arm64, và vấn đề xuất hiện sau thay đổi framebuffer ở bản 7.3
  Cách giải quyết duy nhất trước đây là tắt trình điều khiển kernel, nhưng giờ có lẽ nhiều người sẽ dùng thử OpenBSD mà không gặp vấn đề
  • Tôi cũng là một trong số đó. Tôi đã muốn dùng thử một thời gian rồi, nhưng chiếc MacBook Pro là máy duy nhất tôi có nên không làm được
  • Tôi thắc mắc vì sao QEMU lại phải khởi động X. Chẳng phải đó là việc của OpenBSD sao
• Đây là câu chuyện về Virtualization.framework (VMM first-party của Apple)
  OpenBSD từ lâu đã hoạt động với tổ hợp Hypervisor.framework + QEMU
  • Tên gọi quá dễ gây nhầm lẫn. Gần như không thể phân biệt hai framework này
  • Tôi không rõ lắm, nhưng có phải cái đó được đưa vào từ Tahoe không? Tôi tò mò vì sao giờ lại giải quyết được thứ trước đây không làm được
  • Tôi cũng bị nhầm. UTM dùng QEMU ở bên dưới, nhưng giờ snapshot OpenBSD khởi động mượt trong QEMU. Dù vậy nó vẫn là môi trường đã được ảo hóa
• Có thể tôi đã bỏ sót gì đó, nhưng khi thử VM tôi gặp vấn đề là bộ nhớ một khi đã tăng thì không bao giờ giảm lại
  Nếu đây là vấn đề thực sự thì tôi muốn biết đã có cải thiện gì chưa
  • Để máy khách báo cho máy chủ rằng “phần bộ nhớ này đã được giải phóng hoàn toàn, anh có thể thu hồi” là việc khá phức tạp
    Ngược lại, để máy khách tin rằng nó có 4GiB RAM nhưng thực tế máy chủ chỉ cấp phát khi được truy cập thì đơn giản hơn nhiều
    VM là một thứ hoàn toàn khác với container
  • Tôi tò mò bạn đã thử VM ở đâu. Trên toàn thế giới có hàng trăm triệu VM chạy mỗi ngày
• Có hướng dẫn nào để tự làm việc này không? Tôi chưa từng dùng hypervisor thô
  • Tìm nhanh trên Kagi thì tôi thấy bài blog này. Có thể nó sẽ hữu ích
  • Về cơ bản chỉ cần tạo kernel và, nếu cần, RAM disk rồi khởi động như Linux
• Hơi liên quan một chút, nhưng UTM Remote là một ứng dụng khách điều khiển VM từ xa thực sự rất tuyệt
  Tôi mong nó cũng hỗ trợ các giao thức hypervisor khác (libvirtd, bhyve, v.v.)
• Tôi tò mò liệu OpenBSD khi chạy dưới dạng máy khách có đủ an toàn không
  Tôi muốn biết nó có được cô lập đến mức máy chủ không thể xâm nhập về mặt toán học hay không. Có lẽ sẽ rất lý tưởng cho quản lý khóa
  • Tính đến năm 2025, OpenBSD hỗ trợ AMD SEV/SEV-ES, và SEV-SNP đang được phát triển
    Nếu có phần cứng phù hợp thì hoàn toàn có thể cô lập đủ tốt
    Nội dung liên quan cũng được đề cập trong bài thuyết trình BSDCan 2025
  • Nhưng kernel của máy chủ và VMM vẫn có thể nhìn thấy bộ nhớ máy khách. Tôi không khuyến nghị dùng cho mục đích đó
• Xin lưu ý, fork Redox này là thuần Rust và hoàn toàn không có Makefile
• Làm tốt lắm! Hiện tại FreeBSD 15 hoàn toàn không chạy được X trong UTM
  Tình huống hiện giờ là chỉ dùng được RDP/VNC, nên tôi hy vọng với cải tiến lần này framebuffer cũng sẽ hoạt động