From: cdall@kernel.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
Date: Mon, 4 Dec 2017 20:31:51 +0100 [thread overview]
Message-ID: <20171204193151.GG32397@cbox> (raw)
In-Reply-To: <20171129151314.el7ndd2czsglw7lh@kamzik.brq.redhat.com>
On Wed, Nov 29, 2017 at 04:13:14PM +0100, Andrew Jones wrote:
> On Mon, Nov 20, 2017 at 08:16:47PM +0100, Christoffer Dall wrote:
> > For mapped IRQs (with the HW bit set in the LR) we have to follow some
> > rules of the architecture. One of these rules is that VM must not be
> > allowed to deactivate a virtual interrupt with the HW bit set unless the
> > physical interrupt is also active.
> >
> > This works fine when injecting mapped interrupts, because we leave it up
> > to the injector to either set EOImode==1 or manually set the active
> > state of the physical interrupt.
> >
> > However, the guest can set virtual interrupt to be pending or active by
> > writing to the virtual distributor, which could lead to deactivating a
> > virtual interrupt with the HW bit set without the physical interrupt
> > being active.
> >
> > We could set the physical interrupt to active whenever we are about to
> > enter the VM with a HW interrupt either pending or active, but that
> > would be really slow, especially on GICv2. So we take the long way
> > around and do the hard work when needed, which is expected to be
> > extremely rare.
> >
> > When the VM sets the pending state for a HW interrupt on the virtual
> > distributor we set the active state on the physical distributor, because
> > the virtual interrupt can become active and then the guest can
> > deactivate it.
> >
> > When the VM clears the pending state we also clear it on the physical
> > side, because the injector might otherwise raise the interrupt. We also
> > clear the physical active state when the virtual interrupt is not
> > active, since otherwise a SPEND/CPEND sequence from the guest would
> > prevent signaling of future interrupts.
> >
> > Changing the state of mapped interrupts from userspace is not supported,
> > and it's expected that userspace unmaps devices from VFIO before
> > attempting to set the interrupt state, because the interrupt state is
> > driven by hardware.
> >
> > Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > virt/kvm/arm/vgic/vgic-mmio.c | 71 +++++++++++++++++++++++++++++++++++++++----
> > virt/kvm/arm/vgic/vgic.c | 7 +++++
> > virt/kvm/arm/vgic/vgic.h | 1 +
> > 3 files changed, 73 insertions(+), 6 deletions(-)
> >
> > diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> > index 6113cf850f47..294e949ece24 100644
> > --- a/virt/kvm/arm/vgic/vgic-mmio.c
> > +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> > @@ -16,6 +16,7 @@
> > #include <linux/kvm.h>
> > #include <linux/kvm_host.h>
> > #include <kvm/iodev.h>
> > +#include <kvm/arm_arch_timer.h>
> > #include <kvm/arm_vgic.h>
> >
> > #include "vgic.h"
> > @@ -142,10 +143,22 @@ static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
> > return vcpu;
> > }
> >
> > +/* Must be called with irq->irq_lock held */
> > +static void vgic_hw_irq_spending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> > + bool is_uaccess)
> > +{
> > + if (!is_uaccess)
> > + irq->pending_latch = true;
> > +
> > + if (!is_uaccess)
> > + vgic_irq_set_phys_active(irq, true);
>
> I see this whole patch has this two 'if (!is_uaccess)' checks pattern.
> Is that meant to convey something?
Yeah, that I'm a fool.
> Or is the first condition not supposed
> to have the '!'? (I'm lost with regards to the state tracking differences
> between the guest and userspace and just reviewing superficially...)
>
This became weird becaus the first clause used to be "if (!is_uaccess ||
is_timer)", but now when the timer is interrupt driven (the timer
optimization series), we don't have that concept anymore, and I just
blindly removes the "|| is_timer" part.
I reworked this so that the functions now have
if (is_uaccess)
return;
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-12-04 19:31 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
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 [this message]
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=20171204193151.GG32397@cbox \
--to=cdall@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).