From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <cdall@linaro.org>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
Andre Przywara <andre.przywara@arm.com>
Subject: Re: [RFC PATCH 2/4] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
Date: Sat, 02 Sep 2017 12:04:06 +0100 [thread overview]
Message-ID: <867exhuztl.fsf@arm.com> (raw)
In-Reply-To: <20170829093902.15379-3-cdall@linaro.org> (Christoffer Dall's message of "Tue, 29 Aug 2017 11:39:00 +0200")
On Tue, Aug 29 2017 at 11:39:00 am BST, Christoffer Dall <cdall@linaro.org> wrote:
> Level-triggered mapped IRQs are special because we only observe rising
> edges as input to the VGIC, and we don't set the EOI flag and therefore
> are not told when the level goes down, so that we can re-queue a new
> interrupt when the level goes up.
>
> One way to solve this problem is to side-step the logic of the VGIC and
> special case the validation in the injection path, but it has the
> unfortunate drawback of having to peak into the physical GIC state
> whenever we want to know if the interrupt is pending on the virtual
> distributor.
>
> Instead, we can maintain the current semantics of a level triggered
> interrupt by sort of treating it as an edge-triggered interrupt,
> following from the fact that we only observe an asserting edge. This
> requires us to be a bit careful when populating the LRs and when folding
> the state back in though:
>
> * We lower the line level when populating the LR, so that when
> subsequently observing an asserting edge, the VGIC will do the right
> thing.
>
> * If the guest never acked the interrupt while running (for example if
> it had masked interrupts at the CPU level while running), we have
> to preserve the pending state of the LR and move it back to the
> line_level field of the struct irq when folding LR state.
>
> If the guest never acked the interrupt while running, but changed the
> device state and lowered the line (again with interrupts masked) then
> we need to observe this change in the line_level.
>
> Both of the above situations are solved by sampling the physical line
> and set the line level when folding the LR back.
>
> * Finally, if the guest never acked the interrupt while running and
> sampling the line reveals that the device state has changed and the
> line has been lowered, we must clear the physical active state, since
> we will otherwise never be told when the interrupt becomes asserted
> again.
>
> This has the added benefit of making the timer optimization patches
> (https://lists.cs.columbia.edu/pipermail/kvmarm/2017-July/026343.html) a
> bit simpler, because the timer code doesn't have to clear the active
> state on the sync anymore. It also potentially improves the performance
> of the timer implementation because the GIC knows the state or the LR
> and only needs to clear the
> active state when the pending bit in the LR is still set, where the
> timer has to always clear it when returning from running the guest with
> an injected timer interrupt.
>
> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> ---
> virt/kvm/arm/vgic/vgic-v2.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 29 +++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.c | 23 +++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.h | 7 +++++++
> 4 files changed, 88 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index e4187e5..f7c5cb5 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -104,6 +104,26 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
> irq->pending_latch = false;
> }
>
> + /*
> + * Level-triggered mapped IRQs are special because we only
> + * observe rising edges as input to the VGIC.
> + *
> + * If the guest never acked the interrupt we have to sample
> + * the physical line and set the line level, because the
> + * device state could have changed or we simply need to
> + * process the still pending interrupt later.
> + *
> + * If this causes us to lower the level, we have to also clear
> + * the physical active state, since we will otherwise never be
> + * told when the interrupt becomes asserted again.
> + */
> + if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) {
I've just had a worrying though. Here, we're looking at the guest's view
of the trigger. But shouldn't that be the *host's*? We're assuming that
the two should match, and while they certainly do for the timer, this is
not something that can be enforced for SPIs.
What do you think?
M.
--
Jazz is not dead. It just smells funny.
next prev parent reply other threads:[~2017-09-02 11:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 9:38 [RFC PATCH 0/4] Handle forwarded level-triggered interrupts Christoffer Dall
2017-08-29 9:38 ` [RFC PATCH 1/4] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq Christoffer Dall
2017-09-02 11:13 ` Marc Zyngier
2017-08-29 9:39 ` [RFC PATCH 2/4] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts Christoffer Dall
2017-08-30 8:19 ` Auger Eric
2017-08-30 9:20 ` Christoffer Dall
2017-08-30 10:13 ` Auger Eric
2017-08-30 12:03 ` Christoffer Dall
2017-08-30 12:57 ` Auger Eric
2017-09-02 10:52 ` Marc Zyngier
2017-09-02 20:37 ` Christoffer Dall
2017-09-02 11:04 ` Marc Zyngier [this message]
2017-09-02 20:23 ` Christoffer Dall
2017-08-29 9:39 ` [RFC PATCH 3/4] KVM: arm/arm64: Rearrange kvm_vgic_[un]map_phys code in vgic.c Christoffer Dall
2017-09-02 11:14 ` Marc Zyngier
2017-08-29 9:39 ` [RFC PATCH 4/4] KVM: arm/arm64: Provide a vgic interrupt line level sample function Christoffer Dall
2017-09-02 11:20 ` Marc Zyngier
2017-09-02 20:41 ` 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=867exhuztl.fsf@arm.com \
--to=marc.zyngier@arm.com \
--cc=andre.przywara@arm.com \
--cc=cdall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
/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