Re: port-arm/60655: vmt(4) probes the VMware backdoor unconditionally on aarch64 and panics the kernel on hypervisors that do not implement it

["zakinko%snowrabbit.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-arm/60655; it has been noted by GNATS.

From: zakinko%snowrabbit.org@localhost
To: gnats-bugs%NetBSD.org@localhost
Cc: port-arm-maintainer%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
	gnats-admin%NetBSD.org@localhost, skrll%NetBSD.org@localhost, zakinko%snowrabbit.org@localhost
Subject: Re: port-arm/60655: vmt(4) probes the VMware backdoor unconditionally on aarch64 and panics the kernel on hypervisors that do not implement it
Date: Sat,  5 Sep 2026 00:40:00 +0900 (JST)

 qemu-system-aarch64 11.1.0 from Homebrew, on macOS 26.6.2 (build 25G83),
 on an Apple M4.  The accelerator is what matters here, and I have now
 measured both.
 
 	-accel hvf	panics
 	-accel tcg	boots to login
 
 Same image, same GENERIC64 kernel (NetBSD 11.99.7; 11.0 behaves the same).
 The only difference is the accelerator, so if you were using TCG that would
 explain why it does not fail for you.
 
 With hvf:
 
 	qemu-system-aarch64 \
 		-M virt -accel hvf -cpu host -smp 6 -m 8G \
 		-drive if=pflash,format=raw,readonly=on,file=edk2-aarch64-code.fd \
 		-drive if=pflash,format=raw,file=varstore.img \
 		-drive if=none,file=arm64.img,format=raw,id=hd0 \
 		-device virtio-blk-pci,drive=hd0 \
 		-display none -serial unix:console.sock,server,nowait
 
 	[   1.0000000] cpu0 at acpi0: unknown CPU (ID = 0x610f0000), id 0x0
 	[   1.0000000] panic: Trap: fatal Unknown Reason (Illegal Instruction)
 
 With tcg, the same invocation but -accel tcg -cpu cortex-a72:
 
 	[   1.0000000] cpu0 at acpi0: Arm Cortex-A72 r0p3 (v8-A), id 0x0
 	...
 	login:
 
 The read of `mrs xzr, mdccsr_el0` succeeds under TCG because QEMU implements
 that system register itself, so vmt_probe() returns and vmt(4) simply decides
 it is not running under VMware.  Under hvf the instruction reaches the real
 CPU through Hypervisor.framework, nothing intercepts it, and it raises an
 undefined instruction exception at EL1.
 
 The CPU line differs too: hvf reports the host M4 as an unknown CPU, TCG
 reports the modelled Cortex-A72.
 
 I cannot test KVM here; this host is macOS, where the only accelerators are
 hvf and tcg.
 
 One caveat on the TCG run, so as not to overstate it: it panicked once with
 "cpu0: softints stuck for 16 seconds" and rebooted, which I take to be TCG
 being slow rather than anything to do with vmt(4).  It reached login on the
 following boot.  There is no vmt-related panic anywhere in that log.