Re: panic in wscons booting current evbarm64 iso under virtualization on Apple Silicon

[Chris Hanson <cmhanson%eschatologist.net@localhost>]

On Oct 25, 2026, at 8:01 PM, Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:
> 
> On Oct 25, 2026, at 5:50 PM, Jonathan A. Kollasch <jakllsch%kollasch.net@localhost> wrote:
>> 
>> It looks like what happened is genfb(4) called wsdisplay_cnattach(), and
>> then viogpu(4) called it again, and wsdisplay_cnattach() insists on only
>> being called once.  The question becomes why both genfb and viogpu are
>> trying to run what's probably the same framebuffer as console.
> 
> I think what may be going on is that genfb(4) is being matched because a generic frame buffer shows up in the device tree:
> 
> [   1.0000040] genfb0 at simplebus1: Simple Framebuffer (800x600 32-bpp @ 0x13bd00000)
> [   1.0000040] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)
> 
> and viogpu(4) is being used because that generic frame buffer is a virtio-ramfb device in QEMU and thus *also* found via VirtIO:
> 
> [   1.0000040] virtio33 at pci0 dev 2 function 0
> [   1.0000040] virtio33: GPU device (id 16, rev. 0x01)
> [   1.0000040] viogpu0 at virtio33: features: 0x110000000<V1,INDIRECT_DESC>
> [   1.0000040] virtio33: interrupting at irq 37
> 
> Would this be a QEMU bug, or a bug in the handling/interaction of device tree and VirtIO in NetBSD?

Either way, that definitely seems to be what’s going on:

If I tweak simplefb_match() to return 0, viogpu gets the console and everything works from there.

  -- Chris