mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-07-16 17:57:38 -04:00
KVM: arm64: timers: Convert per-vcpu virtual offset to a global value
Having a per-vcpu virtual offset is a pain. It needs to be synchronized on each update, and expands badly to a setup where different timers can have different offsets, or have composite offsets (as with NV). So let's start by replacing the use of the CNTVOFF_EL2 shadow register (which we want to reclaim for NV anyway), and make the virtual timer carry a pointer to a VM-wide offset. This simplifies the code significantly. It also addresses two terrible bugs: - The use of CNTVOFF_EL2 leads to some nice offset corruption when the sysreg gets reset, as reported by Joey. - The kvm mutex is taken from a vcpu ioctl, which goes against the locking rules... Reported-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230224173915.GA17407@e124191.cambridge.arm.com Tested-by: Joey Gouly <joey.gouly@arm.com> Link: https://lore.kernel.org/r/20230224191640.3396734-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
This commit is contained in:
committed by
Oliver Upton
parent
fe15c26ee2
commit
47053904e1
@@ -23,6 +23,19 @@ enum kvm_arch_timer_regs {
|
||||
TIMER_REG_CTL,
|
||||
};
|
||||
|
||||
struct arch_timer_offset {
|
||||
/*
|
||||
* If set, pointer to one of the offsets in the kvm's offset
|
||||
* structure. If NULL, assume a zero offset.
|
||||
*/
|
||||
u64 *vm_offset;
|
||||
};
|
||||
|
||||
struct arch_timer_vm_data {
|
||||
/* Offset applied to the virtual timer/counter */
|
||||
u64 voffset;
|
||||
};
|
||||
|
||||
struct arch_timer_context {
|
||||
struct kvm_vcpu *vcpu;
|
||||
|
||||
@@ -32,6 +45,8 @@ struct arch_timer_context {
|
||||
/* Emulated Timer (may be unused) */
|
||||
struct hrtimer hrtimer;
|
||||
|
||||
/* Offset for this counter/timer */
|
||||
struct arch_timer_offset offset;
|
||||
/*
|
||||
* We have multiple paths which can save/restore the timer state onto
|
||||
* the hardware, so we need some way of keeping track of where the
|
||||
|
||||
Reference in New Issue
Block a user