From patchwork Fri Jun 9 17:41:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andre Przywara X-Patchwork-Id: 9779003 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 6046D603B4 for ; Fri, 9 Jun 2017 17:44:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4A099286E2 for ; Fri, 9 Jun 2017 17:44:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3EBF6286E0; Fri, 9 Jun 2017 17:44:02 +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 692A7286E2 for ; Fri, 9 Jun 2017 17:44:00 +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 1dJNva-0004co-KK; Fri, 09 Jun 2017 17:42:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJNvZ-0004Yf-Lu for xen-devel@lists.xenproject.org; Fri, 09 Jun 2017 17:42:29 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id BA/79-26106-40EDA395; Fri, 09 Jun 2017 17:42:28 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRWlGSWpSXmKPExsVysyfVTZflnlW kwdMdohbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8bZ+XeYC+7JVWxZdZOxgXGTWBcjF4eQwGZG icnbzzJCOMsZJdYt28LaxcjJwSagK7Hj5mtmEFtEIFTi6YLvzCBFzALXGSVO75jPBpIQFrCW2 HbtLpjNIqAqcfx8C1gzL1D8w/TbYLaEgJxEw/n7YIM4Qer3rAWrFxKwkmg5dJl9AiP3AkaGVY waxalFZalFukZGeklFmekZJbmJmTm6hgbGermpxcWJ6ak5iUnFesn5uZsYgT6uZ2Bg3ME49YT fIUZJDiYlUd5pBVaRQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4e+4A5QSLUtNTK9Iyc4DBBpOW 4OBREuF9cRIozVtckJhbnJkOkTrFqCglzmsJ0icAksgozYNrgwX4JUZZKWFeRgYGBiGegtSi3 MwSVPlXjOIcjErCvLtApvBk5pXATX8FtJgJaPGSdxYgi0sSEVJSDYzGjQKxnWLtu+bwGVyZ/a 3kqnnKt4M3u08tZjeJP1p383/jUaZf+tPWiuXvz4hb8of51c4HQovP2SZvv5yR3zn35x2Dq8/ TC2MuKXyMPrP5VU3cLcnVfU1GXCvFkk2PHyoJuvIhw/fb5k0vH/8pY7C32Jpl8/6h9uEc9Xnu pkLyyr9V7D4enlCkxFKckWioxVxUnAgAzWqCqGsCAAA= X-Env-Sender: andre.przywara@arm.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1497030147!104928227!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 33021 invoked from network); 9 Jun 2017 17:42:28 -0000 Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by server-3.tower-31.messagelabs.com with SMTP; 9 Jun 2017 17:42:28 -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 656901596; Fri, 9 Jun 2017 10:42:27 -0700 (PDT) Received: from e104803-lin.lan (unknown [10.1.207.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1CBE83F578; Fri, 9 Jun 2017 10:42:25 -0700 (PDT) From: Andre Przywara To: Julien Grall , Stefano Stabellini Date: Fri, 9 Jun 2017 18:41:38 +0100 Message-Id: <20170609174141.5068-32-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 31/34] ARM: vITS: handle INVALL command 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 The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just iterate over all mapped LPIs and filter for those from that particular VCPU. Signed-off-by: Andre Przywara Acked-by: Julien Grall --- xen/arch/arm/vgic-v3-its.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c index d0d64c7..d3e0324 100644 --- a/xen/arch/arm/vgic-v3-its.c +++ b/xen/arch/arm/vgic-v3-its.c @@ -504,6 +504,82 @@ out_unlock_its: return ret; } +/* + * INVALL updates the per-LPI configuration status for every LPI mapped to + * a particular redistributor. + * We iterate over all mapped LPIs in our radix tree and update those. + */ +static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr) +{ + uint32_t collid = its_cmd_get_collection(cmdptr); + struct vcpu *vcpu; + struct pending_irq *pirqs[16]; + uint64_t vlpi = 0; /* 64-bit to catch overflows */ + unsigned int nr_lpis, i; + unsigned long flags; + int ret = 0; + + /* + * As this implementation walks over all mapped LPIs, it might take + * too long for a real guest, so we might want to revisit this + * implementation for DomUs. + * However this command is very rare, also we don't expect many + * LPIs to be actually mapped, so it's fine for Dom0 to use. + */ + ASSERT(is_hardware_domain(its->d)); + + /* + * If no redistributor has its LPIs enabled yet, we can't access the + * property table, so there is no point in executing this command. + * The control flow dependency here and a barrier instruction on the + * write side make sure we can access these without taking a lock. + */ + if ( !its->d->arch.vgic.rdists_enabled ) + return 0; + + spin_lock(&its->its_lock); + vcpu = get_vcpu_from_collection(its, collid); + spin_unlock(&its->its_lock); + + spin_lock_irqsave(&vcpu->arch.vgic.lock, flags); + read_lock(&its->d->arch.vgic.pend_lpi_tree_lock); + + do + { + int err; + + nr_lpis = radix_tree_gang_lookup(&its->d->arch.vgic.pend_lpi_tree, + (void **)pirqs, vlpi, + ARRAY_SIZE(pirqs)); + + for ( i = 0; i < nr_lpis; i++ ) + { + /* We only care about LPIs on our VCPU. */ + if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id ) + continue; + + vlpi = pirqs[i]->irq; + /* If that fails for a single LPI, carry on to handle the rest. */ + err = update_lpi_property(its->d, pirqs[i]); + if ( !err ) + update_lpi_vgic_status(vcpu, pirqs[i]); + else + ret = err; + } + /* + * Loop over the next gang of pending_irqs until we reached the end of + * a (fully populated) tree or the lookup function returns less LPIs than + * it has been asked for. + */ + } while ( (++vlpi < its->d->arch.vgic.nr_lpis) && + (nr_lpis == ARRAY_SIZE(pirqs)) ); + + read_unlock(&its->d->arch.vgic.pend_lpi_tree_lock); + spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags); + + return ret; +} + /* Must be called with the ITS lock held. */ static int its_discard_event(struct virt_its *its, uint32_t vdevid, uint32_t vevid) @@ -862,6 +938,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its) case GITS_CMD_INV: ret = its_handle_inv(its, command); break; + case GITS_CMD_INVALL: + ret = its_handle_invall(its, command); + break; case GITS_CMD_MAPC: ret = its_handle_mapc(its, command); break;