diff options
| author | Marc Zyngier <maz@kernel.org> | 2026-08-06 10:10:21 +0100 |
|---|---|---|
| committer | Oliver Upton <oupton@kernel.org> | 2026-08-08 11:10:56 -0700 |
| commit | 8c774604b6ecaca495fa3d27c21593269627f48f (patch) | |
| tree | 5238510dfcb9c3c1112bcb28f3c21ab3ca67663e /include/linux/timerqueue.h | |
| parent | 8053393680d4fa3eb962667d2be95dd39f0940e5 (diff) | |
KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page
We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make
our life easier. But this is not something that the architecture
anticipate.
As a consequence, a hypervisor is free to set VNCR_EL2 to
some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly
accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with
the same VA. Yes, this is odd, but apparently legal.
A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being
flipped. But doing this is a not a good idea for us (we'd need to
trap SCTLR accesses), and wouldn't scale as we nest deeper.
Instead, use the fact that the S1 MMU being off at the point of
translation is cached in our TLB, and if it doesn't match the current
MMU state, leave the VNCR unmapped.
Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-4-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Diffstat (limited to 'include/linux/timerqueue.h')
0 files changed, 0 insertions, 0 deletions
