summaryrefslogtreecommitdiffstats
path: root/arch/arm64/kvm/vmid.c
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2022-11-13 16:38:18 +0000
committerMarc Zyngier <maz@kernel.org>2022-11-17 15:39:35 +0000
commitbead02204e9806807bb290137b1ccabfcb4b16fd (patch)
treea603a35ff45acc982e077c60d6ebdabd5f0ccb28 /arch/arm64/kvm/vmid.c
parentd017eeabd5092565c3dd1c8a7b00ba724c33c18f (diff)
downloadlinux-bead02204e9806807bb290137b1ccabfcb4b16fd.tar.bz2
KVM: arm64: PMU: Align chained counter implementation with architecture pseudocode
Ricardo recently pointed out that the PMU chained counter emulation in KVM wasn't quite behaving like the one on actual hardware, in the sense that a chained counter would expose an overflow on both halves of a chained counter, while KVM would only expose the overflow on the top half. The difference is subtle, but significant. What does the architecture say (DDI0087 H.a): - Up to PMUv3p4, all counters but the cycle counter are 32bit - A 32bit counter that overflows generates a CHAIN event on the adjacent counter after exposing its own overflow status - The CHAIN event is accounted if the counter is correctly configured (CHAIN event selected and counter enabled) This all means that our current implementation (which uses 64bit perf events) prevents us from emulating this overflow on the lower half. How to fix this? By implementing the above, to the letter. This largely results in code deletion, removing the notions of "counter pair", "chained counters", and "canonical counter". The code is further restructured to make the CHAIN handling similar to SWINC, as the two are now extremely similar in behaviour. Reported-by: Ricardo Koller <ricarkol@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20221113163832.3154370-3-maz@kernel.org
Diffstat (limited to 'arch/arm64/kvm/vmid.c')
0 files changed, 0 insertions, 0 deletions