diff options
author | Marc Zyngier <maz@kernel.org> | 2025-04-29 12:43:26 +0100 |
---|---|---|
committer | Oliver Upton <oliver.upton@linux.dev> | 2025-05-05 12:19:24 -0700 |
commit | 859c60276e12a3a18c65a3f9325e656a068c9b62 (patch) | |
tree | 0b20e8389c6f85779146585d2851083c2b639dd0 /tools/perf/util/scripting-engines/trace-event-python.c | |
parent | 157dbc4a321f5bb6f8b6c724d12ba720a90f1a7c (diff) | |
download | linux-stable-859c60276e12a3a18c65a3f9325e656a068c9b62.tar.gz linux-stable-859c60276e12a3a18c65a3f9325e656a068c9b62.tar.bz2 linux-stable-859c60276e12a3a18c65a3f9325e656a068c9b62.zip |
KVM: arm64: Force HCR_EL2.xMO to 1 at all times in VHE mode
We keep setting and clearing these bits depending on the role of
the host kernel, mimicking what we do for nVHE. But that's actually
pretty pointless, as we always want physical interrupts to make it
to the host, at EL2.
This has also two problems:
- it prevents IRQs from being taken when these bits are cleared
if the implementation has chosen to implement these bits as
masks when HCR_EL2.{TGE,xMO}=={0,0}
- it triggers a bad erratum on the AmpereOne HW, which catches
fire on clearing these bits while an interrupt is being taken
(AC03_CPU_36).
Let's kill these two birds with a single stone, and permanently
set the xMO bits when running VHE. This involves a bit of surgery
on code paths that rely on flipping these bits on and off for
other purposes.
Note that the earliest setting of hcr_el2 (in the init_hcr_el2
macro) is left untouched as is runs extremely early, with interrupts
disabled, and soon enough overwritten with the final value containing
the xMO bits.
Reported-by: D Scott Phillips <scott@os.amperecomputing.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250429114326.3618875-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions