* Re: pKVM breakage in mainline on n1sdp
2026-02-21 10:33 ` Marc Zyngier
@ 2026-02-21 10:38 ` Marc Zyngier
2026-02-21 12:35 ` Marc Zyngier
2026-02-21 13:42 ` Mark Brown
2026-02-21 13:16 ` Mark Brown
2026-02-22 8:34 ` Fuad Tabba
2 siblings, 2 replies; 10+ messages in thread
From: Marc Zyngier @ 2026-02-21 10:38 UTC (permalink / raw)
To: Mark Brown, Fuad Tabba
Cc: Oliver Upton, Catalin Marinas, Will Deacon, Suzuki K Poulose,
Joey Gouly, kvmarm, linux-arm-kernel, Mark Rutland
On Sat, 21 Feb 2026 10:33:47 +0000,
Marc Zyngier <maz@kernel.org> wrote:
>
> [+ 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.
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pKVM breakage in mainline on n1sdp
2026-02-21 10:38 ` Marc Zyngier
@ 2026-02-21 12:35 ` Marc Zyngier
2026-02-21 13:42 ` Mark Brown
1 sibling, 0 replies; 10+ messages in thread
From: Marc Zyngier @ 2026-02-21 12:35 UTC (permalink / raw)
To: Mark Brown, Fuad Tabba
Cc: Oliver Upton, Catalin Marinas, Will Deacon, Suzuki K Poulose,
Joey Gouly, kvmarm, linux-arm-kernel, Mark Rutland
On Sat, 21 Feb 2026 10:38:05 +0000,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Sat, 21 Feb 2026 10:33:47 +0000,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > [+ 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.
>
> 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?
Things get super bizarre with a host compiled with 16kB pages and in
protected mode. I still can't trigger the warning, but tests stop
making forward progress, and even running a simple Linux kernel guest
with kvmtool hangs.
A bit of tracing indicates that at least in the last case, we're stuck
taking an translation fault on instruction fetch at level 3. But
that's clearly not new, as even 6.18 is affected.
Again, not sure the two things are related, but this needs
investigating.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pKVM breakage in mainline on n1sdp
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
1 sibling, 1 reply; 10+ messages in thread
From: Mark Brown @ 2026-02-21 13:42 UTC (permalink / raw)
To: Marc Zyngier
Cc: Fuad Tabba, Oliver Upton, Catalin Marinas, Will Deacon,
Suzuki K Poulose, Joey Gouly, kvmarm, linux-arm-kernel,
Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Sat, Feb 21, 2026 at 10:38:05AM +0000, Marc Zyngier wrote:
> If that's vanilla 6.19, then there is post Feb 8th. Sorry for the
> unwarranted rant.
It won't be vanilla v6.19, that specific log will be tip of Linus' tree
from yesterday morning UK time which should be 8bf22c33e7a1 ("Merge tag
'net-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"),
there were a few results for commits over the day prior to that showing
the same behaviour.
> Can you share the configuration for this kernel?
It should be an arm64 defconfig (I'm having trouble connecting to the
relevant systems right now to double check).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: pKVM breakage in mainline on n1sdp
2026-02-21 13:42 ` Mark Brown
@ 2026-02-23 10:05 ` Mark Rutland
2026-02-23 14:27 ` Mark Brown
0 siblings, 1 reply; 10+ messages in thread
From: Mark Rutland @ 2026-02-23 10:05 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Fuad Tabba, Oliver Upton, Catalin Marinas,
Will Deacon, Suzuki K Poulose, Joey Gouly, kvmarm,
linux-arm-kernel
On Sat, Feb 21, 2026 at 01:42:52PM +0000, Mark Brown wrote:
> On Sat, Feb 21, 2026 at 10:38:05AM +0000, Marc Zyngier wrote:
>
> > If that's vanilla 6.19, then there is post Feb 8th. Sorry for the
> > unwarranted rant.
>
> It won't be vanilla v6.19, that specific log will be tip of Linus' tree
> from yesterday morning UK time which should be 8bf22c33e7a1 ("Merge tag
> 'net-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"),
> there were a few results for commits over the day prior to that showing
> the same behaviour.
Are you sure? That log says:
CPU: 1 UID: 0 PID: 1955 Comm: qemu-system-aar Not tainted 6.19.0 #1 PREEMPT
... where "6.19.0" means that's the 6.19 tag, and "#1" means that's the
first build against that.
Is the build system overriding things such that this is misleading?
Is there potentially a problem with the build system?
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: pKVM breakage in mainline on n1sdp
2026-02-23 10:05 ` Mark Rutland
@ 2026-02-23 14:27 ` Mark Brown
0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2026-02-23 14:27 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Fuad Tabba, Oliver Upton, Catalin Marinas,
Will Deacon, Suzuki K Poulose, Joey Gouly, kvmarm,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
On Mon, Feb 23, 2026 at 10:05:46AM +0000, Mark Rutland wrote:
> On Sat, Feb 21, 2026 at 01:42:52PM +0000, Mark Brown wrote:
> > It won't be vanilla v6.19, that specific log will be tip of Linus' tree
> > from yesterday morning UK time which should be 8bf22c33e7a1 ("Merge tag
> > 'net-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"),
> > there were a few results for commits over the day prior to that showing
> > the same behaviour.
> Are you sure? That log says:
> CPU: 1 UID: 0 PID: 1955 Comm: qemu-system-aar Not tainted 6.19.0 #1 PREEMPT
> ... where "6.19.0" means that's the 6.19 tag, and "#1" means that's the
> first build against that.
The UI claims that we're seeing this in 956b9cbd7f156 (Merge tag
'kbuild-fixes-7.0-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux) but
unfortunately the build logs don't clearly confirm this.
All the builds are fresh builds in a new container so it would be
surprising if we reported a build number other than 1.
> Is the build system overriding things such that this is misleading?
I believe that to be the case here, the builds are not building from a
git checkout but rather the build coordination is packing a tarball of
the source up then handing that off to be built on a separate system
which means that the magic to figure out the git describe and put that
into the version number during the build can't do anything and just
reports whatever is in the Makefile.
> Is there potentially a problem with the build system?
I can't 100% discount that possibility but it does seem to DTRT for
other commits and has done for a long time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pKVM breakage in mainline on n1sdp
2026-02-21 10:33 ` Marc Zyngier
2026-02-21 10:38 ` Marc Zyngier
@ 2026-02-21 13:16 ` Mark Brown
2026-02-22 8:34 ` Fuad Tabba
2 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2026-02-21 13:16 UTC (permalink / raw)
To: Marc Zyngier
Cc: Fuad Tabba, Oliver Upton, Catalin Marinas, Will Deacon,
Suzuki K Poulose, Joey Gouly, kvmarm, linux-arm-kernel,
Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
On Sat, Feb 21, 2026 at 10:33:47AM +0000, Marc Zyngier wrote:
> On Fri, 20 Feb 2026 19:08:59 +0000,
> Mark Brown <broonie@kernel.org> wrote:
> > 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:
> 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.
As mentioned above this is with mainline, that is to say with Linus'
tree.
kvm-unit-tests should be at commit 0ed2cdf3c8 ("arm64: Fix sve_vl() for
build errors"), though it doesn't announce a version at runtime (and we
should really update from there, especially once the next release
happens which will hopefully be soon).
> > 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.
Indeed, one of the other machines that wasn't showing these issues for
me was an Altra.
> 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?
Yes, there are a bunch of other long standing failures in protected
mode, like can be seen with this run on i.MX8MP for Linus' tip of tree:
https://lava.sirena.org.uk/scheduler/job/2478171#L1365
which is a lot less happy than the non-pKVM run for the same commit on
the same board:
https://lava.sirena.org.uk/scheduler/job/2478178#L1360
(those runs will have a more recent kvm-unit-tests version, it's
separate infrastructure). I don't recall those tests ever working with
pKVM.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: pKVM breakage in mainline on n1sdp
2026-02-21 10:33 ` Marc Zyngier
2026-02-21 10:38 ` Marc Zyngier
2026-02-21 13:16 ` Mark Brown
@ 2026-02-22 8:34 ` Fuad Tabba
2026-02-23 16:26 ` Mark Brown
2 siblings, 1 reply; 10+ messages in thread
From: Fuad Tabba @ 2026-02-22 8:34 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Brown, Oliver Upton, Catalin Marinas, Will Deacon,
Suzuki K Poulose, Joey Gouly, kvmarm, linux-arm-kernel,
Mark Rutland
On Sat, 21 Feb 2026 at 10:33, Marc Zyngier <maz@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@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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: pKVM breakage in mainline on n1sdp
2026-02-22 8:34 ` Fuad Tabba
@ 2026-02-23 16:26 ` Mark Brown
0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2026-02-23 16:26 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, Catalin Marinas, Will Deacon,
Suzuki K Poulose, Joey Gouly, kvmarm, linux-arm-kernel,
Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Sun, Feb 22, 2026 at 08:34:57AM +0000, Fuad Tabba wrote:
> On Sat, 21 Feb 2026 at 10:33, Marc Zyngier <maz@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/
Followed up there, that looks to be it - thanks again!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread