From patchwork Fri Jun 9 17:41:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andre Przywara X-Patchwork-Id: 9778977 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1A10360318 for ; Fri, 9 Jun 2017 17:43:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 061DA286E0 for ; Fri, 9 Jun 2017 17:43:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EEAAA286E7; Fri, 9 Jun 2017 17:43:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9FD6B286E0 for ; Fri, 9 Jun 2017 17:43:46 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJNvT-0004IR-6e; Fri, 09 Jun 2017 17:42:23 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJNvR-0004Dp-MW for xen-devel@lists.xenproject.org; Fri, 09 Jun 2017 17:42:21 +0000 Received: from [193.109.254.147] by server-4.bemta-6.messagelabs.com id 62/00-02956-DFDDA395; Fri, 09 Jun 2017 17:42:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRWlGSWpSXmKPExsVysyfVTffPXat Ig55jChbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8bq9mUsBYs0Kq48XcDYwPhZrouRi0NIYDOj xM2Ha9ghnOWMEg0TZjB1MXJysAnoSuy4+ZoZxBYRCJV4uuA7M0gRs8B1RonTO+azgSSEBawl3 ix5xQJiswioSvxp3wtUxMHBCxRvnhgNEpYQkJNoOH8fbA4nUHjbnrVgrUICVhIthy6zT2DkXs DIsIpRozi1qCy1SNfQSC+pKDM9oyQ3MTNH19DATC83tbg4MT01JzGpWC85P3cTI9DDDECwg/H yxoBDjJIcTEqivNMKrCKF+JLyUyozEosz4otKc1KLDzHKcHAoSfC+ugOUEyxKTU+tSMvMAYYa TFqCg0dJhPfFSaA0b3FBYm5xZjpE6hSjopQ470aQPgGQREZpHlwbLLwvMcpKCfMyAh0ixFOQW pSbWYIq/4pRnINRSZjXEBgtQjyZeSVw018BLWYCWrzknQXI4pJEhJRUA2NmurfLwVOzWpbNN1 lkLNLxJWPmwbYAiVO907PLeIqyT3ecvLeL1cMwpNXoxzarlqhGu+xupb/TpxsasV4TSr+47AW rd/jjgyw/Pu060bYu/3JTwPb6uOgZXzUNfZOUOSaue+Wx85jtY65/PnHhH42yCtT3hV7dW7Vk gd/LbR+menC9vzXNP0mJpTgj0VCLuag4EQA9t8DdagIAAA== X-Env-Sender: andre.przywara@arm.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1497030139!107125594!1 X-Originating-IP: [217.140.101.70] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20671 invoked from network); 9 Jun 2017 17:42:20 -0000 Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by server-6.tower-27.messagelabs.com with SMTP; 9 Jun 2017 17:42:20 -0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AD8E91596; Fri, 9 Jun 2017 10:42:19 -0700 (PDT) Received: from e104803-lin.lan (unknown [10.1.207.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 642F23F578; Fri, 9 Jun 2017 10:42:18 -0700 (PDT) From: Andre Przywara To: Julien Grall , Stefano Stabellini Date: Fri, 9 Jun 2017 18:41:33 +0100 Message-Id: <20170609174141.5068-27-andre.przywara@arm.com> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20170609174141.5068-1-andre.przywara@arm.com> References: <20170609174141.5068-1-andre.przywara@arm.com> Cc: xen-devel@lists.xenproject.org, Vijaya Kumar K , Vijay Kilari , Shanker Donthineni , Manish Jaggi Subject: [Xen-devel] [PATCH v11 26/34] ARM: GICv3: handle unmapped LPIs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Acked-by: Julien Grall --- 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 9597ef8..b337a86 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); @@ -440,6 +442,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 ( unlikely(test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status)) ) + { + unsigned int used_lr; + + for_each_set_bit(used_lr, lr_mask, 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) { @@ -455,7 +491,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); @@ -478,8 +515,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)); @@ -589,7 +632,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;