summaryrefslogtreecommitdiff
path: root/arch/arm64/kvm
diff options
context:
space:
mode:
authorAlexandru Elisei <alexandru.elisei@arm.com>2020-01-27 10:36:52 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-14 16:34:18 -0500
commit0ec337059d71e9a2f66f223d47a9ae428a435c41 (patch)
tree101692ae1d96d4ea6d41a560c44fcc84aaa6d6bf /arch/arm64/kvm
parenta17d21640453719e6f7a9de53d2982f0f7b2357b (diff)
KVM: arm64: Treat emulated TVAL TimerValue as a signed 32-bit integer
commit 4a267aa707953a9a73d1f5dc7f894dd9024a92be upstream. According to the ARM ARM, registers CNT{P,V}_TVAL_EL0 have bits [63:32] RES0 [1]. When reading the register, the value is truncated to the least significant 32 bits [2], and on writes, TimerValue is treated as a signed 32-bit integer [1, 2]. When the guest behaves correctly and writes 32-bit values, treating TVAL as an unsigned 64 bit register works as expected. However, things start to break down when the guest writes larger values, because (u64)0x1_ffff_ffff = 8589934591. but (s32)0x1_ffff_ffff = -1, and the former will cause the timer interrupt to be asserted in the future, but the latter will cause it to be asserted now. Let's treat TVAL as a signed 32-bit register on writes, to match the behaviour described in the architecture, and the behaviour experimentally exhibited by the virtual timer on a non-vhe host. [1] Arm DDI 0487E.a, section D13.8.18 [2] Arm DDI 0487E.a, section D11.2.4 Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> [maz: replaced the read-side mask with lower_32_bits] Signed-off-by: Marc Zyngier <maz@kernel.org> Fixes: 8fa761624871 ("KVM: arm/arm64: arch_timer: Fix CNTP_TVAL calculation") Link: https://lore.kernel.org/r/20200127103652.2326-1-alexandru.elisei@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/arm64/kvm')
0 files changed, 0 insertions, 0 deletions