From: Andre Przywara <andre.przywara@arm.com>
To: Christoffer Dall <christoffer.dall@linaro.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Cc: kvm@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v5 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
Date: Fri, 1 Dec 2017 18:04:55 +0000 [thread overview]
Message-ID: <bf436ce1-1908-ff74-386b-45870c04a133@arm.com> (raw)
In-Reply-To: <20171120191649.17290-4-christoffer.dall@linaro.org>
Hi,
On 20/11/17 19:16, Christoffer Dall wrote:
> The timer was modeled after a strict idea of modelling an interrupt line
> level in software, meaning that only transitions in the level needed to
> be reported to the VGIC. This works well for the timer, because the
> arch timer code is in complete control of the device and can track the
> transitions of the line.
>
> However, as we are about to support using the HW bit in the VGIC not
> just for the timer, but also for VFIO which cannot track transitions of
> the interrupt line, we have to decide on an interface for level
> triggered mapped interrupts to the GIC, which both the timer and VFIO
> can use.
>
> VFIO only sees an asserting transition of the physical interrupt line,
> and tells the VGIC when that happens. That means that part of the
> interrupt flow is offloaded to the hardware.
>
> To use the same interface for VFIO devices and the timer, we therefore
> have to change the timer (we cannot change VFIO because it doesn't know
> the details of the device it is assigning to a VM).
>
> Luckily, changing the timer is simple, we just need to stop 'caching'
> the line level, but instead let the VGIC know the state of the timer
> every time there is a potential change in the line level, and when the
> line level should be asserted from the timer ISR. The VGIC can ignore
> extra notifications using its validate mechanism.
Indeed vgic_validate_injection() should take care of that change.
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
> ---
> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 190c99ed1b73..5f8ad8e3f3ff 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> - kvm_timer_update_irq(vcpu, true, vtimer);
> - }
> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(vtimer))
> + kvm_timer_update_irq(vcpu, true, vtimer);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> kvm_vtimer_update_mask_user(vcpu);
> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> + bool level;
>
> if (unlikely(!timer->enabled))
> return;
>
> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
> + /*
> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
> + * of its lifecycle is offloaded to the hardware, and we therefore may
> + * not have lowered the irq.level value before having to signal a new
> + * interrupt, but have to signal an interrupt every time the level is
> + * asserted.
> + */
> + level = kvm_timer_should_fire(vtimer);
> + kvm_timer_update_irq(vcpu, level, vtimer);
>
> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>
next prev parent reply other threads:[~2017-12-01 18:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 19:16 [PATCH v5 0/8] Handle forwarded level-triggered interrupts Christoffer Dall
2017-11-20 19:16 ` [PATCH v5 1/8] KVM: arm/arm64: Remove redundant preemptible checks Christoffer Dall
2017-12-01 18:04 ` Andre Przywara
2017-11-20 19:16 ` [PATCH v5 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu Christoffer Dall
2017-12-01 18:04 ` Andre Przywara
2017-12-04 19:21 ` Christoffer Dall
2017-11-20 19:16 ` [PATCH v5 3/8] KVM: arm/arm64: Don't cache the timer IRQ level Christoffer Dall
2017-12-01 18:04 ` Andre Przywara [this message]
2017-11-20 19:16 ` [PATCH v5 4/8] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts Christoffer Dall
2017-11-20 19:16 ` [PATCH v5 5/8] KVM: arm/arm64: Support a vgic interrupt line level sample function Christoffer Dall
2017-11-20 19:16 ` [PATCH v5 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs Christoffer Dall
2017-11-29 15:13 ` Andrew Jones
2017-12-04 19:31 ` Christoffer Dall
2017-11-20 19:16 ` [PATCH v5 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer Christoffer Dall
2017-11-29 15:13 ` Andrew Jones
2017-11-20 19:16 ` [PATCH v5 8/8] KVM: arm/arm64: Avoid work when userspace iqchips are not used Christoffer Dall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf436ce1-1908-ff74-386b-45870c04a133@arm.com \
--to=andre.przywara@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox