Re: kern/60284: NetBSD guest kernel panics with qemu + hvf on a MacOS Tahoe 26.5 host

[Sunil Nimmagadda <sunil%nimmagadda.net@localhost>]

"Nick Hudson via gnats" <gnats-admin%NetBSD.org@localhost> wrote:
> The following reply was made to PR kern/60284; it has been noted by GNATS.
> 
> From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
> To: gnats-bugs%netbsd.org@localhost,
>  kern-bug-people%netbsd.org@localhost,
>  gnats-admin%netbsd.org@localhost,
>  netbsd-bugs%netbsd.org@localhost
> Cc: 
> Subject: Re: kern/60284: NetBSD guest kernel panics with qemu + hvf on a MacOS
>  Tahoe 26.5 host
> Date: Thu, 21 May 2026 16:07:13 +0100
> 
>  On 21/05/2026 15:20, sunil%nimmagadda.net@localhost via gnats wrote:
>  >> Number:         60284
>  >> Category:       kern
>  >> Synopsis:       NetBSD guest kernel panics with qemu + hvf on a MacOS =
>  Tahoe 26.5 host
>  >> Confidential:   no
>  >> Severity:       serious
>  >> Priority:       medium
>  >> Responsible:    kern-bug-people
>  >> State:          open
>  >> Class:          sw-bug
>  >> Submitter-Id:   net
>  >> Arrival-Date:   Thu May 21 14:20:00 +0000 2026
>  >> Originator:     Sunil Nimmagadda
>  >> Release:        HEAD
>  >> Organization:
>  >> Environment:
>  > Darwin IN-MV47KDX4PH 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 =
>  20:41:15 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6041 arm64
>  >> Description:
>  > Running a NetBSD vm with qemu + hvf acceleration on MacOS with this =
>  invocation worked until the update to Tahoe 26.5...
>  > qemu-system-aarch64 \
>  >   -M virt \
>  >   -cpu cortex-a57 \
>  >   -accel hvf \
>  >   -smp 4 \
>  >   -m 8g \
>  >   -nodefaults \
>  >   -nographic \
>  >   -serial mon:stdio \
>  >   -kernel netbsd-GENERIC64.img \
>  >   -append "root=3Ddk1" \
>  >   -drive if=3Dnone,file=3Darm64.img,format=3Draw,id=3Dhd0 \
>  >   -device virtio-blk-device,drive=3Dhd0 \
>  >   -netdev type=3Duser,id=3Dnet0,ipv6=3Doff,hostfwd=3Dtcp:127.0.0.1:2229-=
>  :22 \
>  >   -device virtio-net-device,netdev=3Dnet0 \
>  >   -object rng-random,filename=3D/dev/urandom,id=3Dviornd0 \
>  >   -device virtio-rng-device,rng=3Dviornd0 \
>  > After the update on the host the hvf aborts with...
>  > Assertion failed: (write_cpustate_to_list(arm_cpu, false)), function =
>  hvf_arch_init_vcpu, file hvf.c, line 1328.
>  > ./qemu.sh: line 20: 91674 Abort trap: 6
>  
>  Really not sure about this one.
>  
>  
>  > Trying to use '-cpu host' with qemu like this...
>  > qemu-system-aarch64 \
>  >   -M virt \
>  >   -cpu host \
>  >   -accel hvf \
>  >   -smp 4 \
>  >   -m 8g \
>  >   -nodefaults \
>  >   -nographic \
>  >   -serial mon:stdio \
>  >   -kernel netbsd-GENERIC64.img \
>  >   -append "root=3Ddk1" \
>  >   -drive if=3Dnone,file=3Darm64.img,format=3Draw,id=3Dhd0 \
>  >   -device virtio-blk-device,drive=3Dhd0 \
>  >   -netdev type=3Duser,id=3Dnet0,ipv6=3Doff,hostfwd=3Dtcp:127.0.0.1:2229-=
>  :22 \
>  >   -device virtio-net-device,netdev=3Dnet0 \
>  >   -object rng-random,filename=3D/dev/urandom,id=3Dviornd0 \
>  >   -device virtio-rng-device,rng=3Dviornd0 \
>  > results in the NetBSD guest kernel panic...
>  > [   1.0000040] panic: kernel diagnostic assertion "armv8_pmu_detect()" =
>  failed: file "/usr/src/sys/dev/tprof/tprof_armv8.c", line 281
>  > [   1.0000040] cpu3: Begin traceback...
>  > [   1.0000040] trace fp ffffc002b8043c40
>  > [   1.0000040] fp ffffc002b8043c70 vpanic() at ffffc000005e4684 =
>  netbsd:vpanic+0x1bc
>  > [   1.0000040] fp ffffc002b8043cd0 kern_assert() at ffffc0000088bff8 =
>  netbsd:kern_assert+0x58
>  > [   1.0000040] fp ffffc002b8043d60 armv8_pmu_init() at =
>  ffffc000000c9cc4 netbsd:armv8_pmu_init+0xe4
>  > [   1.0000040] fp ffffc002b8043d80 pmu_fdt_init() at ffffc00000078708 =
>  netbsd:pmu_fdt_init+0x284
>  > [   1.0000040] fp ffffc002b8043e90 config_interrupts_thread() at =
>  ffffc000005bfd50 netbsd:config_interrupts_thread+0xac
>  > [   1.0000040] tf ffffc002b8043ed0 el0_trap() at ffffc000000c07f0 =
>  netbsd:el1_trap_exit+0x68
>  > [   1.0722237] cpu3: End traceback...
>  
>  I think -cpu host,pmu=3Doff should fix this.
>  
>  Apple silicon doesn=E2=80=99t have an Arm ARM compatible PMU
>  
>  

Thanks, with pmu=off, it works as expected.