pKVM breakage in mainline on n1sdp

[Fuad Tabba]

On Sat, 21 Feb 2026 at 10:33, Marc Zyngier <maz at kernel.org> wrote:
>
> [+ Fuad for the protected mode stuff]

I'm unable to reproduce it, but I think the following might be the fix:
https://lore.kernel.org/all/20260222083352.89503-1-tabba@google.com/

Thanks for catching this, and sorry for the trouble.

Cheers,
/fuad


> 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.
>
> > The same tests running on N1SDP in VHE mode seem happy, and I've not
> > seen any other platforms showing issues.  Unfortunately due to various
> > infrastructure issues I don't have more detail on when this started
> > happening or anything, I'll update if I get more.
>
> I've ran that test on an Altra (Neoverse-N1, same as N1SDP), with both
> v6.19 and linux/master as of d79526b89571 together with KUT as of
> 86e53277 and nothing caught fire in protected mode, including a
> 32-parallel VM test.
>
> Most of KUT's PMU tests fail in protected mode though, probably due
> some issue with the routing of PMU exceptions (see below), but that
> doesn't seem new. Fuad, could you please have a look and see if
> something catches your eye?
>
> Thanks,
>
>         M.
>
> maz at filthy-habits:~/kvm-unit-tests$ ./arm/run arm/pmu.flat -smp 1 -append 'pmu-mem-access'
> /usr/bin/qemu-system-aarch64 -nodefaults -machine virt,gic-version=host -accel kvm -cpu host -device virtio-serial-device -device virtconsole,chardev=ctd -chardev testdev,id=ctd -device pci-testdev -display none -serial stdio -kernel arm/pmu.flat -smp 1 -append pmu-mem-access # -initrd /tmp/tmp.S6qLYpNV6X
> INFO: PMU version: 0x4
> INFO: PMU implementer/ID code: 0(" ")/0
> INFO: Implements 6 event counters
> INFO: pmu: pmu-mem-access: 32-bit overflows: counter #0 is 0x0 (MEM_ACCESS)
> INFO: pmu: pmu-mem-access: 32-bit overflows: counter #1 is 0x0 (MEM_ACCESS)
> FAIL: pmu: pmu-mem-access: 32-bit overflows: Ran 20 mem accesses
> FAIL: pmu: pmu-mem-access: 32-bit overflows: Ran 20 mem accesses with expected overflows on both counters
> INFO: pmu: pmu-mem-access: 32-bit overflows: cnt#0=0xfffffff0 cnt#1=0xfffffff0 overflow=0x0
> SKIP: pmu: pmu-mem-access: 64-bit overflows: Skip test as 64 overflows need FEAT_PMUv3p5
> SUMMARY: 3 tests, 2 unexpected failures, 1 skipped
>
> EXIT: STATUS=3
>
> --
> Jazz isn't dead. It just smells funny.