pKVM breakage in mainline on n1sdp

[Marc Zyngier]

On Sat, 21 Feb 2026 10:33:47 +0000,
Marc Zyngier <maz at kernel.org> wrote:
> 
> [+ Fuad for the protected mode stuff]
> 
> On Fri, 20 Feb 2026 19:08:59 +0000,
> Mark Brown <broonie at kernel.org> wrote:
> > 
> > Hi,
> > 
> > At some point since the 30th of January we have started seeing issues 
> > in mainline when running kvm-unit-tests on N1SDP in pKVM mode:
> > 
> > TESTNAME=pmu-mem-access TIMEOUT=90s MACHINE= ACCEL= ./arm/run arm/pmu.flat -smp 1 -append 'pmu-mem-access'
> > <4>[  114.487201] ------------[ cut here ]------------
> > <4>[  114.487206] WARNING: arch/arm64/kvm/pkvm.c:393 at pkvm_pgtable_stage2_map+0x1ac/0x1c4, CPU#1: qemu-system-aar/1955
> > <4>[  114.502672] Modules linked in: stm_p_basic coresight_tpiu coresight_stm stm_core arm_spe_pmu coresight_funnel coresight_tmc coresight_replicator coresight arm_cmn sha256 cfg80211 rfkill fuse dm_mod ipv6
> > <4>[  114.520924] CPU: 1 UID: 0 PID: 1955 Comm: qemu-system-aar Not tainted 6.19.0 #1 PREEMPT 
> > <4>[  114.529261] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > <4>[  114.536469] pc : pkvm_pgtable_stage2_map+0x1ac/0x1c4
> > <4>[  114.541681] lr : pkvm_pgtable_stage2_map+0x58/0x1c4
> > <4>[  114.546805] sp : ffff80008673b900
> > <4>[  114.550366] x29: ffff80008673b900 x28: 0000000000200000 x27: 0000000000200000
> > <4>[  114.557748] x26: 0000000000000000 x25: 00000000fffffff4 x24: 000000000000000f
> > <4>[  114.565130] x23: ffff008047b65198 x22: 00000000080cbc00 x21: 0000000000040000
> > <4>[  114.572512] x20: ffff008046f65680 x19: 0000000000000200 x18: 0000000000000001
> > <4>[  114.579893] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > <4>[  114.587275] x14: 0000000000000002 x13: 0000000000000002 x12: 000000000031bf68
> > <4>[  114.594656] x11: 0000000000000000 x10: 0000ffff8be01000 x9 : ffff8000800728b0
> > <4>[  114.602037] x8 : ffff80008673bab8 x7 : 0000000000000001 x6 : 0000000000000008
> > <4>[  114.609419] x5 : 0000000040200000 x4 : 000000000000000f x3 : 0000000000000200
> > <4>[  114.616800] x2 : 0000000000040000 x1 : fffffffffffffff4 x0 : 0000000000000000
> > <4>[  114.624182] Call trace:
> > <4>[  114.626875]  pkvm_pgtable_stage2_map+0x1ac/0x1c4 (P)
> > <4>[  114.632088]  kvm_handle_guest_abort+0xe7c/0x12ec
> > <4>[  114.636953]  handle_exit+0x60/0x184
> > <4>[  114.640689]  kvm_arch_vcpu_ioctl_run+0x35c/0x968
> > <4>[  114.645554]  kvm_vcpu_ioctl+0x254/0xa50
> > <4>[  114.649638]  __arm64_sys_ioctl+0xac/0x104
> > <4>[  114.653896]  invoke_syscall+0x48/0x110
> > <4>[  114.657894]  el0_svc_common.constprop.0+0x40/0xe0
> > <4>[  114.662846]  do_el0_svc+0x1c/0x28
> > <4>[  114.666409]  el0_svc+0x34/0x10c
> > <4>[  114.669798]  el0t_64_sync_handler+0xa0/0xe4
> > <4>[  114.674228]  el0t_64_sync+0x198/0x19c
> > <4>[  114.678137] ---[ end trace 0000000000000000 ]---
> >
> 
> The absence of any versioning information is really unhelpful. What
> kernel version is that? Upstream? Next? A date really doesn't help
> much, specially given how vague it is. Same thing for KUT.

Ah no, I can't read:

[  114.520924] CPU: 1 UID: 0 PID: 1955 Comm: qemu-system-aar Not tainted 6.19.0 #1 PREEMPT

If that's vanilla 6.19, then there is post Feb 8th. Sorry for the
unwarranted rant.

Can you share the configuration for this kernel?

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.