OpenBSD-current agora pode rodar como guest no Apple Hypervisor

• OpenBSD/arm64 agora pode operar como sistema operacional guest no ambiente Apple Hypervisor
• Por meio de uma série de commits, processamento gráfico e recursos de rede foram corrigidos e aprimorados, resolvendo pânicos de kernel e o problema de tela preta no X11
• Agora funciona completamente no ambiente Apple Virtualization e pode ser usado nos mais recentes Macs com Apple Silicon

---

Suporte ao OpenBSD/arm64 no Apple Hypervisor

• Com commits recentes, o OpenBSD/arm64 agora pode ser executado como sistema operacional guest no Apple Hypervisor
  • Os commits relacionados foram feitos por Helg Bredow(helg@) e Stefan Fritsch(sf@)

Correção de viogpu por Helg Bredow

• A função viogpu_wsmmap() no arquivo sys/dev/pv/viogpu.c foi modificada
  • Antes ela retornava um endereço virtual do kernel (kva), mas agora retorna um endereço físico por meio de bus_dmamem_mmap(9)
  • Essa correção resolveu o problema de tela preta ao executar X11 no QEMU e o pânico de kernel no Apple Hypervisor
• Foi adicionada uma chamada a bus_dmamap_sync(9) antes de transferir o framebuffer para a memória do host
  • Com isso, o host em execução em outra CPU consegue perceber as atualizações do framebuffer
  • A revisão e o feedback da correção foram feitos por kettenis@, e a aprovação (ok) foi dada por sf@

Correção de rede virtio por Stefan Fritsch

• Foi adicionado suporte ao recurso VIRTIO_NET_F_MTU no arquivo sys/dev/pv/if_vio.c
  • O valor hardmtu é obtido do hipervisor e o MTU atual é configurado com esse mesmo valor
  • Embora o padrão virtio não seja claro, foi adotada a mesma abordagem do Linux
• ETHER_MAX_HARDMTU_LEN é usado como limite superior, oferecendo um tratamento mais preciso do que o antigo MAXMCLBYTES
  • Se o hipervisor solicitar um MTU maior do que isso, a renegociação é feita sem o recurso VIRTIO_NET_F_MTU
• Com esse commit, o OpenBSD passa a funcionar completamente no ambiente Apple Virtualization
  • Contribuições e testes foram feitos por helg@, e a aprovação (ok) foi dada por jan@

Orientação aos usuários e recomendação de testes

• Essa mudança é especialmente útil para usuários dos modelos mais recentes de Mac com Apple Silicon
• No momento, ela pode ser testada na versão snapshot, e feedback dos usuários é solicitado

[GN⁺]

Comentários no Hacker News

• Ótima atualização. A negociação de VIRTIO_NET_F_MTU era um obstáculo para implementações de vários sistemas operacionais convidados na pilha de virtualização da Apple
  Como a especificação era ambígua, o Linux simplesmente funcionava, mas o OpenBSD precisou de um patch separado para lidar com limites rígidos de MTU
  Graças ao desempenho de thread única dos chips M4/M5, um guest OpenBSD é um ambiente ideal para testar configurações de pf ou rodar um servidor de e-mail isolado
  Agora dá para usar o viogpu de forma estável, então já não é mais preciso ficar preso ao console serial ao fazer instalações rápidas de VM
  Muitos aplausos para Helg e Stefan
  • Um unikernel talvez fosse ainda melhor. Mas, nesse caso, seria necessário um unikernel para servidor de e-mail que possa funcionar sem um sistema operacional
  • Eu não preciso desse ambiente gráfico. Minha IaC (infraestrutura como código) não deve exigir nenhuma interação ao subir uma VM
• A notícia maior é que esta atualização corrigiu um bug de compatibilidade com o QEMU
  Por causa desse bug, o OpenBSD travava ao iniciar o X em arm64, um problema que surgiu depois das mudanças no framebuffer da versão 7.3
  A única solução era desativar o driver do kernel, mas agora parece que mais gente vai conseguir usar o OpenBSD sem problemas
  • Eu sou uma dessas pessoas. Já faz um tempo que queria experimentar, mas minha única máquina é um MacBook Pro
  • Fico me perguntando por que o QEMU precisaria iniciar o X. Isso não seria papel do OpenBSD?
• Isso é sobre o Virtualization.framework (o VMM de primeira parte da Apple)
  O OpenBSD já funcionava há muito tempo com a combinação Hypervisor.framework + QEMU
  • Os nomes são confusos demais. É quase impossível diferenciar os dois frameworks
  • Não tenho certeza, mas isso foi introduzido no Tahoe? Queria entender por que agora resolveram algo que antes não era possível
  • Eu também me confundi. O UTM usa QEMU internamente, mas agora o snapshot do OpenBSD inicializa de forma tranquila no QEMU. Ainda continua virtualizado, claro
• Posso estar deixando algo passar, mas ao testar VMs havia um problema em que a memória, depois de aumentar uma vez, nunca mais diminuía
  Se isso for uma questão real, queria saber se houve alguma melhora
  • Fazer o guest informar ao host “eu liberei completamente esta memória, então você pode recuperá-la” é algo bem complexo
    Já o contrário — o guest acreditar que tem 4 GiB de RAM, enquanto o host só aloca de fato quando há acesso — é muito mais simples
    VMs são algo totalmente diferente de contêineres
  • Fico curioso para saber onde você testou a VM. Existem centenas de milhões de VMs rodando todos os dias no mundo todo
• Existe algum guia para fazer isso na prática? Nunca usei um hypervisor bruto
  • Com uma busca rápida no Kagi, encontrei este post de blog. Talvez ajude
  • Basicamente, basta criar o kernel e, se necessário, um disco RAM, e então inicializar como no Linux
• Um pouco relacionado ao assunto, mas o UTM Remote é um cliente remoto de VM realmente excelente
  Gostaria que ele também suportasse outros protocolos de hypervisor (libvirtd, bhyve etc.)
• Fico curioso se o OpenBSD, rodando como guest, oferece segurança suficiente
  Queria saber se ele fica isolado a ponto de o host não conseguir invadi-lo nem matematicamente. Talvez fosse ideal para gerenciamento de chaves
  • Em 2025, o OpenBSD oferece suporte a AMD SEV/SEV-ES, e o SEV-SNP está em desenvolvimento
    Com o hardware adequado, o isolamento pode ser suficiente
    Isso também é abordado na apresentação da BSDCan 2025
  • Mas o kernel do host e o VMM ainda podem ver a memória do guest. Eu não recomendaria isso para esse tipo de uso
• Para referência, este fork do Redox é totalmente baseado em Rust e não tem nenhum Makefile
• Muito bom! No momento, o FreeBSD 15 simplesmente não faz o X funcionar no UTM
  Só é possível usar RDP/VNC, então espero que essa melhoria permita que o framebuffer passe a funcionar