# OpenBSD-current, 이제 Apple Hypervisor에서 게스트로 실행 가능

> Clean Markdown view of GeekNews topic #25894. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25894](https://news.hada.io/topic?id=25894)
- GeekNews Markdown: [https://news.hada.io/topic/25894.md](https://news.hada.io/topic/25894.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-17T09:43:48+09:00
- Updated: 2026-01-17T09:43:48+09:00
- Original source: [undeadly.org](https://www.undeadly.org/cgi?action=article;sid=20260115203619)
- Points: 2
- Comments: 1

## Topic Body

- **OpenBSD/arm64**가 **Apple Hypervisor** 환경에서 게스트 운영체제로 동작 가능해짐  
- 일련의 커밋을 통해 **그래픽 처리와 네트워크 기능**이 수정 및 개선되어 커널 패닉과 X11 블랙스크린 문제 해결  
- 이제 Apple Virtualization 환경에서 완전하게 동작하며, 최신 **Apple Silicon Mac** 에서 이용 가능  
  
---  
  
### Apple Hypervisor에서의 OpenBSD/arm64 지원  
- 최근 커밋을 통해 **[OpenBSD/arm64](https://www.openbsd.org/arm64.html)** 가 **[Apple Hypervisor](https://developer.apple.com/documentation/hypervisor)** 에서 게스트 운영체제로 실행 가능  
  - 관련 커밋은 Helg Bredow(`helg@`)와 Stefan Fritsch(`sf@`)가 수행   
  
### Helg Bredow의 viogpu 수정  
- `sys/dev/pv/viogpu.c` 파일에서 **viogpu_wsmmap()** 함수가 수정됨  
  - 기존에는 커널 가상 주소(kva)를 반환했으나, 이제 **bus_dmamem_mmap(9)** 을 통해 물리 주소를 반환  
  - 이 수정으로 QEMU에서 X11 실행 시 발생하던 **검은 화면 문제**와 Apple Hypervisor에서의 **커널 패닉**이 해결됨  
- 프레임버퍼를 호스트 메모리로 전송하기 전 **bus_dmamap_sync(9)** 호출 추가  
  - 이를 통해 다른 CPU에서 실행 중인 호스트가 프레임버퍼 업데이트를 인식 가능  
  - 수정 검토와 피드백은 kettenis@가 수행, 승인(ok)은 sf@가 부여  
  
### Stefan Fritsch의 virtio 네트워크 수정  
- `sys/dev/pv/if_vio.c` 파일에서 **VIRTIO_NET_F_MTU 기능** 지원 추가  
  - 하이퍼바이저로부터 **hardmtu 값을 가져와** 현재 MTU를 동일하게 설정  
  - virtio 표준이 명확하지 않지만, **Linux와 동일한 방식**을 채택  
- **ETHER_MAX_HARDMTU_LEN**을 상한으로 사용하여 이전의 **MAXMCLBYTES**보다 정확한 처리  
  - 하이퍼바이저가 이보다 큰 MTU를 요청할 경우, **VIRTIO_NET_F_MTU 기능 없이 재협상** 수행  
- 이 커밋으로 **OpenBSD가 Apple Virtualization 환경에서 완전하게 동작**  
  - 입력 및 테스트는 helg@가 수행, 승인(ok)은 jan@가 부여  
  
### 사용자 안내 및 테스트 권장  
- 이 변경은 **최신 Apple Silicon Mac 모델 사용자**에게 특히 유용  
- 현재 **스냅샷 버전**에서 테스트 가능하며, 사용자 피드백 요청

## Comments



### Comment 49373

- Author: neo
- Created: 2026-01-17T09:43:48+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46642560) 
- 좋은 업데이트임. **VIRTIO_NET_F_MTU 협상**이 Apple 가상화 스택에서 여러 게스트 OS 구현의 걸림돌이었음  
  스펙이 모호해서 Linux는 그냥 작동하지만 OpenBSD는 하드 MTU 제한을 처리하기 위해 별도 패치를 넣어야 했음  
  M4/M5 칩의 단일 스레드 성능 덕분에 OpenBSD 게스트는 pf 설정 테스트나 격리된 메일 서버 실행에 최적의 환경임  
  이제 **viogpu**를 안정적으로 쓸 수 있어서, 빠른 VM 설치 시 시리얼 콘솔만 쓰던 방식에서 벗어날 수 있게 됨  
  Helg와 Stefan에게 큰 박수를 보냄
  - 유니커널(unikernel)이면 더 좋을지도 모름. 다만 그 경우엔 OS 없이 동작할 수 있는 **메일 서버용 유니커널**이 필요함
  - 나는 그런 그래픽 환경이 필요 없음. 내 **IaC(인프라 코드)** 는 VM을 띄울 때 어떤 상호작용도 원하지 않음
- 더 큰 소식은 이 업데이트가 **QEMU 호환성 버그**를 해결했다는 점임  
  이 버그 때문에 arm64에서 OpenBSD가 X를 시작할 때 멈췄는데, 7.3 버전의 프레임버퍼 변경 이후 생긴 문제였음  
  유일한 해결책은 커널 드라이버를 비활성화하는 것이었는데, 이제 더 많은 사람들이 OpenBSD를 문제 없이 써볼 수 있을 것 같음
  - 나도 그중 한 명임. 한동안 써보고 싶었는데, 내 유일한 머신이 **MacBook Pro**라서 못 했음
  - QEMU가 X를 시작해야 하는 이유가 뭔지 궁금함. 그건 OpenBSD의 역할 아닌가 싶음
- 이건 **Virtualization.framework**(Apple의 1st-party VMM)에 관한 이야기임  
  OpenBSD는 오래전부터 **Hypervisor.framework + QEMU** 조합으로도 작동했음
  - 이름이 너무 헷갈림. 두 프레임워크를 구분하기가 거의 불가능함
  - 잘 모르겠는데, 그게 **Tahoe**에서 도입된 거였나? 이전엔 불가능했던 걸 해결한 이유가 궁금함
  - 나도 혼동했음. **UTM**은 내부적으로 QEMU를 쓰지만, 이제 OpenBSD 스냅샷이 QEMU에서 매끄럽게 부팅됨. 여전히 가상화된 상태이긴 함
- 내가 뭔가 놓친 걸 수도 있지만, VM을 테스트할 때 메모리가 한 번 커지면 절대 **줄어들지 않는 문제**가 있었음  
  이게 실제 이슈라면 개선이 있는지 궁금함
  - 게스트가 호스트에게 “이 메모리를 완전히 해제했으니 회수해도 된다”고 알려주는 건 꽤 복잡한 일임  
    반대로 게스트가 4GiB RAM이 있다고 믿지만 실제로는 접근할 때만 호스트가 할당하는 건 훨씬 단순함  
    **VM은 컨테이너와 완전히 다른 존재**임
  - VM을 어디서 테스트했는지 궁금함. 전 세계적으로 수억 개의 VM이 매일 돌아가고 있음
- 이걸 직접 해보는 **가이드**가 있을까? 나는 raw hypervisor를 써본 적이 없음
  - 빠른 Kagi 검색으로 [이 블로그 글](https://briancallahan.net/blog/20250222.html)을 찾았음. 아마 도움이 될 수도 있음
  - 기본적으로 커널과 필요 시 RAM 디스크를 만들어서 Linux처럼 부팅하면 됨
- 약간 관련된 이야기지만, **UTM Remote**는 정말 훌륭한 VM 원격 클라이언트임  
  다른 하이퍼바이저 프로토콜(libvirtd, bhyve 등)도 지원해줬으면 함
- OpenBSD가 게스트로 실행될 때 **보안성**이 충분한지 궁금함  
  호스트가 수학적으로 침입할 수 없을 정도로 격리되는지 알고 싶음. 키 관리 용도로 이상적일 수도 있음
  - 2025년 기준 OpenBSD는 **AMD SEV/SEV-ES**를 지원하고, **SEV-SNP**는 개발 중임  
    적절한 하드웨어가 있다면 충분히 격리 가능함  
    관련 내용은 [BSDCan 2025 발표](https://www.bsdcan.org/2025/timetable/timetable-Confidential-Computing-with.html)에서도 다뤄짐
  - 하지만 호스트 커널과 VMM은 여전히 게스트 메모리를 볼 수 있음. 그런 용도로는 추천하지 않음
- 참고로 [이 Redox fork](https://github.com/pannous/redox)는 완전히 **Rust 기반**이며 Makefile이 전혀 없음
- 잘했음! 현재 **FreeBSD 15**는 UTM에서 X가 전혀 작동하지 않음  
  RDP/VNC만 가능한 상황인데, 이번 개선으로 프레임버퍼가 동작할 수 있길 기대함