2019-05-30 02:57:47 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2013-01-23 22:21:58 +04:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2012 ARM Ltd.
|
|
|
|
|
* Author: Marc Zyngier <marc.zyngier@arm.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __ASM_ARM_KVM_ARCH_TIMER_H
|
|
|
|
|
#define __ASM_ARM_KVM_ARCH_TIMER_H
|
|
|
|
|
|
|
|
|
|
#include <linux/clocksource.h>
|
|
|
|
|
#include <linux/hrtimer.h>
|
|
|
|
|
|
2018-07-05 18:48:23 +03:00
|
|
|
enum kvm_arch_timers {
|
|
|
|
|
TIMER_PTIMER,
|
|
|
|
|
TIMER_VTIMER,
|
|
|
|
|
NR_KVM_TIMERS
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum kvm_arch_timer_regs {
|
|
|
|
|
TIMER_REG_CNT,
|
|
|
|
|
TIMER_REG_CVAL,
|
|
|
|
|
TIMER_REG_TVAL,
|
|
|
|
|
TIMER_REG_CTL,
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-03 18:19:59 +03:00
|
|
|
struct arch_timer_context {
|
2018-09-18 20:08:18 +03:00
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
|
2017-02-03 18:19:59 +03:00
|
|
|
/* Timer IRQ */
|
|
|
|
|
struct kvm_irq_level irq;
|
|
|
|
|
|
2018-09-18 20:08:18 +03:00
|
|
|
/* Emulated Timer (may be unused) */
|
|
|
|
|
struct hrtimer hrtimer;
|
2019-02-19 16:04:30 +03:00
|
|
|
|
2019-01-04 15:31:22 +03:00
|
|
|
/*
|
|
|
|
|
* 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
|
|
|
|
|
* latest state is.
|
|
|
|
|
*/
|
|
|
|
|
bool loaded;
|
|
|
|
|
|
2019-02-19 16:04:30 +03:00
|
|
|
/* Duplicated state from arch_timer.c for convenience */
|
|
|
|
|
u32 host_timer_irq;
|
|
|
|
|
u32 host_timer_irq_flags;
|
2017-02-03 18:19:59 +03:00
|
|
|
};
|
2013-01-23 22:21:58 +04:00
|
|
|
|
2019-01-04 15:31:22 +03:00
|
|
|
struct timer_map {
|
|
|
|
|
struct arch_timer_context *direct_vtimer;
|
|
|
|
|
struct arch_timer_context *direct_ptimer;
|
|
|
|
|
struct arch_timer_context *emul_ptimer;
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-03 18:19:59 +03:00
|
|
|
struct arch_timer_cpu {
|
2018-09-18 20:08:18 +03:00
|
|
|
struct arch_timer_context timers[NR_KVM_TIMERS];
|
2013-01-23 22:21:58 +04:00
|
|
|
|
|
|
|
|
/* Background timer used when the guest is not running */
|
2017-06-17 17:33:02 +03:00
|
|
|
struct hrtimer bg_timer;
|
2013-01-23 22:21:58 +04:00
|
|
|
|
2016-05-18 18:26:00 +03:00
|
|
|
/* Is the timer enabled */
|
|
|
|
|
bool enabled;
|
2013-01-23 22:21:58 +04:00
|
|
|
};
|
|
|
|
|
|
2017-12-07 14:46:15 +03:00
|
|
|
int kvm_timer_hyp_init(bool);
|
2016-05-18 18:26:00 +03:00
|
|
|
int kvm_timer_enable(struct kvm_vcpu *vcpu);
|
2017-05-02 21:14:06 +03:00
|
|
|
int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
|
2013-01-23 22:21:58 +04:00
|
|
|
void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
|
2020-04-22 10:58:22 +03:00
|
|
|
void kvm_timer_sync_user(struct kvm_vcpu *vcpu);
|
KVM: arm/arm64: Support arch timers with a userspace gic
If you're running with a userspace gic or other interrupt controller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only construct
between the arch timer code and the vgic.
This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
side channel on the kvm_run structure, run->s.regs.device_irq_level, to
always notify userspace of the timer output levels when using a userspace
irqchip.
This works by ensuring that before we enter the guest, if the timer
output level has changed compared to what we last told userspace, we
don't enter the guest, but instead return to userspace to notify it of
the new level. If we are exiting, because of an MMIO for example, and
the level changed at the same time, the value is also updated and
userspace can sample the line as it needs. This is nicely achieved
simply always updating the timer_irq_level field after the main run
loop.
Note that the kvm_timer_update_irq trace event is changed to show the
host IRQ number for the timer instead of the guest IRQ number, because
the kernel no longer know which IRQ userspace wires up the timer signal
to.
Also note that this patch implements all required functionality but does
not yet advertise the capability.
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2016-09-27 22:08:06 +03:00
|
|
|
bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu);
|
|
|
|
|
void kvm_timer_update_run(struct kvm_vcpu *vcpu);
|
2013-01-23 22:21:58 +04:00
|
|
|
void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
|
2014-07-04 18:54:14 +04:00
|
|
|
|
|
|
|
|
u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
|
|
|
|
|
int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
|
|
|
|
|
|
2017-05-02 21:19:15 +03:00
|
|
|
int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
|
|
|
|
|
int kvm_arm_timer_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
|
|
|
|
|
int kvm_arm_timer_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
|
|
|
|
|
|
2017-02-03 18:20:08 +03:00
|
|
|
u64 kvm_phys_timer_read(void);
|
|
|
|
|
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-16 21:30:38 +03:00
|
|
|
void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu);
|
2016-01-29 22:04:48 +03:00
|
|
|
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
|
|
|
|
|
|
2016-12-01 22:32:05 +03:00
|
|
|
void kvm_timer_init_vhe(void);
|
2017-02-03 18:19:59 +03:00
|
|
|
|
2017-10-27 20:34:30 +03:00
|
|
|
bool kvm_arch_timer_get_input_level(int vintid);
|
|
|
|
|
|
2018-09-18 20:08:18 +03:00
|
|
|
#define vcpu_timer(v) (&(v)->arch.timer_cpu)
|
|
|
|
|
#define vcpu_get_timer(v,t) (&vcpu_timer(v)->timers[(t)])
|
|
|
|
|
#define vcpu_vtimer(v) (&(v)->arch.timer_cpu.timers[TIMER_VTIMER])
|
|
|
|
|
#define vcpu_ptimer(v) (&(v)->arch.timer_cpu.timers[TIMER_PTIMER])
|
2018-07-05 18:48:23 +03:00
|
|
|
|
2019-02-19 16:04:30 +03:00
|
|
|
#define arch_timer_ctx_index(ctx) ((ctx) - vcpu_timer((ctx)->vcpu)->timers)
|
|
|
|
|
|
2018-07-05 18:48:23 +03:00
|
|
|
u64 kvm_arm_timer_read_sysreg(struct kvm_vcpu *vcpu,
|
|
|
|
|
enum kvm_arch_timers tmr,
|
|
|
|
|
enum kvm_arch_timer_regs treg);
|
|
|
|
|
void kvm_arm_timer_write_sysreg(struct kvm_vcpu *vcpu,
|
|
|
|
|
enum kvm_arch_timers tmr,
|
|
|
|
|
enum kvm_arch_timer_regs treg,
|
|
|
|
|
u64 val);
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-16 21:30:38 +03:00
|
|
|
|
2019-06-28 17:23:43 +03:00
|
|
|
/* Needed for tracing */
|
|
|
|
|
u32 timer_get_ctl(struct arch_timer_context *ctxt);
|
|
|
|
|
u64 timer_get_cval(struct arch_timer_context *ctxt);
|
|
|
|
|
|
2013-01-23 22:21:58 +04:00
|
|
|
#endif
|
