xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs
Date: Fri, 26 May 2017 18:35:32 +0100	[thread overview]
Message-ID: <20170526173540.10066-25-andre.przywara@arm.com> (raw)
In-Reply-To: <20170526173540.10066-1-andre.przywara@arm.com>

When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same number while the old
LPI is *still* in some LR. To avoid getting the wrong state, we mark
every newly mapped LPI as PRISTINE, which means: has never been in an
LR before. If we detect the LPI in an LR anyway, it must have been an
older one, which we can simply retire.
Before inserting such a PRISTINE LPI into an LR, we must make sure that
it's not already in another LR, as the architecture forbids two
interrupts with the same virtual IRQ number on one CPU.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c         | 51 ++++++++++++++++++++++++++++++++++++++++++----
 xen/include/asm-arm/vgic.h |  6 ++++++
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9e32103..da5ba86 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -375,6 +375,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 {
     ASSERT(!local_irq_is_enabled());
 
+    clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status);
+
     gic_hw_ops->update_lr(lr, p, state);
 
     set_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
@@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
 #endif
 }
 
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
+ * avoid inserting the same IRQ twice. This situation can occur when an
+ * event gets discarded while the LPI is in an LR, and a new LPI with the
+ * same number gets mapped quickly afterwards.
+ */
+static unsigned int gic_find_unused_lr(struct vcpu *v,
+                                       struct pending_irq *p,
+                                       unsigned int lr)
+{
+    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
+    struct gic_lr lr_val;
+
+    ASSERT(spin_is_locked(&v->arch.vgic.lock));
+
+    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
+    {
+        unsigned int used_lr = 0;
+
+        while ( (used_lr = find_next_bit(lr_mask, nr_lrs, used_lr)) < nr_lrs )
+        {
+            gic_hw_ops->read_lr(used_lr, &lr_val);
+            if ( lr_val.virq == p->irq )
+                return used_lr;
+        }
+    }
+
+    lr = find_next_zero_bit(lr_mask, nr_lrs, lr);
+
+    return lr;
+}
+
 void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         unsigned int priority)
 {
@@ -456,7 +492,8 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     if ( v == current && list_empty(&v->arch.vgic.lr_pending) )
     {
-        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
+        i = gic_find_unused_lr(v, p, 0);
+
         if (i < nr_lrs) {
             set_bit(i, &this_cpu(lr_mask));
             gic_set_lr(i, p, GICH_LR_PENDING);
@@ -479,8 +516,14 @@ static void gic_update_one_lr(struct vcpu *v, int i)
     gic_hw_ops->read_lr(i, &lr_val);
     irq = lr_val.virq;
     p = irq_to_pending(v, irq);
-    /* An LPI might have been unmapped, in which case we just clean up here. */
-    if ( unlikely(!p) )
+    /*
+     * An LPI might have been unmapped, in which case we just clean up here.
+     * If that LPI is marked as PRISTINE, the information in the LR is bogus,
+     * as it belongs to a previous, already unmapped LPI. So we discard it
+     * here as well.
+     */
+    if ( unlikely(!p) ||
+         test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
     {
         ASSERT(is_lpi(irq));
 
@@ -590,7 +633,7 @@ static void gic_restore_pending_irqs(struct vcpu *v)
     inflight_r = &v->arch.vgic.inflight_irqs;
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
-        lr = find_next_zero_bit(&this_cpu(lr_mask), nr_lrs, lr);
+        lr = gic_find_unused_lr(v, p, lr);
         if ( lr >= nr_lrs )
         {
             /* No more free LRs: find a lower priority irq to evict */
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 02732db..3fc4ceb 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -60,12 +60,18 @@ struct pending_irq
      * vcpu while it is still inflight and on an GICH_LR register on the
      * old vcpu.
      *
+     * GIC_IRQ_GUEST_PRISTINE_LPI: the IRQ is a newly mapped LPI, which
+     * has never been in an LR before. This means that any trace of an
+     * LPI with the same number in an LR must be from an older LPI, which
+     * has been unmapped before.
+     *
      */
 #define GIC_IRQ_GUEST_QUEUED   0
 #define GIC_IRQ_GUEST_ACTIVE   1
 #define GIC_IRQ_GUEST_VISIBLE  2
 #define GIC_IRQ_GUEST_ENABLED  3
 #define GIC_IRQ_GUEST_MIGRATING   4
+#define GIC_IRQ_GUEST_PRISTINE_LPI  5
     unsigned long status;
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     unsigned int irq;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-05-26 17:36 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 17:35 [PATCH v10 00/32] arm64: Dom0 ITS emulation Andre Przywara
2017-05-26 17:35 ` [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority Andre Przywara
2017-05-30 10:47   ` Julien Grall
2017-05-30 21:39     ` Stefano Stabellini
2017-05-31 10:42       ` Julien Grall
2017-06-02 17:44         ` Julien Grall
2017-06-06 17:06     ` Andre Przywara
2017-06-06 17:11       ` Julien Grall
2017-06-06 17:20         ` Andre Przywara
2017-06-06 17:21           ` Julien Grall
2017-06-06 18:39             ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest Andre Przywara
2017-05-30 10:54   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock Andre Przywara
2017-05-30 11:08   ` Julien Grall
2017-05-30 21:46     ` Stefano Stabellini
2017-05-31 10:44       ` Julien Grall
2017-06-06 17:24     ` Andre Przywara
2017-06-06 18:46       ` Stefano Stabellini
2017-06-07 10:49         ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 04/32] ARM: vGIC: rework gic_remove_from_queues() Andre Przywara
2017-05-30 11:15   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq() Andre Przywara
2017-05-30 11:31   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's Andre Przywara
2017-05-30 11:38   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-06-07 11:19       ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 07/32] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2017-05-26 17:35 ` [PATCH v10 08/32] ARM: GIC: export and extend vgic_init_pending_irq() Andre Przywara
2017-05-26 17:35 ` [PATCH v10 09/32] ARM: vGIC: cache virtual LPI priority in struct pending_irq Andre Przywara
2017-05-26 17:35 ` [PATCH v10 10/32] ARM: vGIC: add LPI VCPU ID to " Andre Przywara
2017-05-26 17:35 ` [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2017-05-30 11:56   ` Julien Grall
2017-05-30 22:07     ` Stefano Stabellini
2017-05-31 11:09       ` Julien Grall
2017-05-31 17:56         ` Stefano Stabellini
2017-05-31 18:39           ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 12/32] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2017-05-30 11:58   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 13/32] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2017-05-26 17:35 ` [PATCH v10 14/32] ARM: introduce vgic_access_guest_memory() Andre Przywara
2017-05-26 17:35 ` [PATCH v10 15/32] ARM: vGICv3: re-use vgic_reg64_check_access Andre Przywara
2017-05-26 17:35 ` [PATCH v10 16/32] ARM: vGIC: advertise LPI support Andre Przywara
2017-05-30 12:59   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation Andre Przywara
2017-06-01 18:13   ` Julien Grall
2017-06-08  9:57   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 18/32] ARM: vITS: introduce translation table walks Andre Przywara
2017-06-02 16:25   ` Julien Grall
2017-06-08  9:35   ` Julien Grall
2017-06-08  9:45     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq Andre Przywara
2017-06-02 16:32   ` Julien Grall
2017-06-02 16:45     ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-06-06 11:13       ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 20/32] ARM: vITS: handle INT command Andre Przywara
2017-06-02 16:37   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 21/32] ARM: vITS: handle MAPC command Andre Przywara
2017-05-26 17:35 ` [PATCH v10 22/32] ARM: vITS: handle CLEAR command Andre Przywara
2017-06-02 16:40   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 23/32] ARM: vITS: handle MAPD command Andre Przywara
2017-06-02 16:46   ` Julien Grall
2017-05-26 17:35 ` Andre Przywara [this message]
2017-06-02 16:55   ` [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs Julien Grall
2017-06-02 20:45     ` Stefano Stabellini
2017-06-08  9:45   ` Julien Grall
2017-06-08 13:51     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command Andre Przywara
2017-06-02 17:12   ` Julien Grall
2017-06-07 17:49     ` Andre Przywara
2017-06-12 16:33       ` Julien Grall
2017-06-09 11:17     ` Andre Przywara
2017-06-09 19:14       ` Stefano Stabellini
2017-06-12 16:10         ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 26/32] ARM: vITS: handle MOVI command Andre Przywara
2017-05-30 22:35   ` Stefano Stabellini
2017-05-31 11:23     ` Julien Grall
2017-05-31 17:53       ` Stefano Stabellini
2017-05-31 18:49         ` Julien Grall
2017-06-02 17:17           ` Julien Grall
2017-06-02 20:36             ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 27/32] ARM: vITS: handle DISCARD command Andre Przywara
2017-06-02 17:21   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 28/32] ARM: vITS: handle INV command Andre Przywara
2017-05-30 22:23   ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 29/32] ARM: vITS: handle INVALL command Andre Przywara
2017-06-02 17:27   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 30/32] ARM: vITS: increase mmio_count for each ITS Andre Przywara
2017-05-26 17:35 ` [PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2017-06-02 17:31   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2017-06-02 17:33   ` Julien Grall

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=20170526173540.10066-25-andre.przywara@arm.com \
    --to=andre.przywara@arm.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=julien.grall@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=vijay.kilari@gmail.com \
    --cc=xen-devel@lists.xenproject.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).