public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>, 	Fuad Tabba <tabba@google.com>
Cc: Oliver Upton <oupton@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Joey Gouly <joey.gouly@arm.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: pKVM breakage in mainline on n1sdp
Date: Sat, 21 Feb 2026 10:33:47 +0000	[thread overview]
Message-ID: <87bjhie67o.wl-maz@kernel.org> (raw)
In-Reply-To: <60916cb6-f460-4751-b910-f63c58700ad0@sirena.org.uk>

[+ Fuad for the protected mode stuff]

On Fri, 20 Feb 2026 19:08:59 +0000,
Mark Brown <broonie@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@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.


  reply	other threads:[~2026-02-21 10:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 19:08 pKVM breakage in mainline on n1sdp Mark Brown
2026-02-21 10:33 ` Marc Zyngier [this message]
2026-02-21 10:38   ` Marc Zyngier
2026-02-21 12:35     ` Marc Zyngier
2026-02-21 13:42     ` Mark Brown
2026-02-23 10:05       ` Mark Rutland
2026-02-23 14:27         ` Mark Brown
2026-02-21 13:16   ` Mark Brown
2026-02-22  8:34   ` Fuad Tabba
2026-02-23 16:26     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bjhie67o.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=oupton@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox