From patchwork Fri Nov 10 08:37:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 10052589 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 376636035D for ; Fri, 10 Nov 2017 08:37:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 24B1E2AD5A for ; Fri, 10 Nov 2017 08:37:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 17F6E2B282; Fri, 10 Nov 2017 08:37:56 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 853252AD5A for ; Fri, 10 Nov 2017 08:37:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751549AbdKJIhx (ORCPT ); Fri, 10 Nov 2017 03:37:53 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:55507 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbdKJIhw (ORCPT ); Fri, 10 Nov 2017 03:37:52 -0500 Received: by mail-wm0-f68.google.com with SMTP id b189so1038768wmd.4 for ; Fri, 10 Nov 2017 00:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gB3jqghxM9B77Z7h9+jiNPAuA0oFGLB43Dt/Tn3ix+M=; b=CMhWF7nIa57h4rS0sj4J4wqF/3hQow+r+Y/rYSk4OV0+BVAY4+TISKvJuXtloDJ7SQ JwtZdR8BV7JbEwx06UM0uVOIPrrI+HdYz1bxfS5fdPpUygerjAeGTtFQEmg3T6Sii9zS iuNCL5m2h5GA3XZbV79nZUSJyTdc+rK034oe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gB3jqghxM9B77Z7h9+jiNPAuA0oFGLB43Dt/Tn3ix+M=; b=az0VAz+e1jqE+3Z/wwNPotSpkZsNXxXHcXVG4o1UX6u5UCp3hcKEguaqXHbk/4g4UG m7k1ZVNdOylVv3nL+7K32yo2A7Wy3fUqnvFv5Efgw5H2LtQsNtn2P7R5ODehLCFOrBU6 +QPub1qPNxkOBfAW2mg9HEO7VtTLEAe3aLj6UUzNWCHOJN7JinahrNDN5wE7O1lHvLtq z4hyXo0UYiOjx8T4z0ciCFnh1RcxmJw7DzAi9eOGh9O9gy+OQzBAkklYYI+0prfYI3HK 4DdVrY5cjFEq3HZQB9QCwaLqxH8EOT5wtis0O6LfBmeSh7UyQSh1E8cN8v6pr1f4k9k+ zA1w== X-Gm-Message-State: AJaThX5aKX1xMaQHsWsZw7oNqB9FV/xmTghqja6enUGbjFKtsdPcpe0j rcIIGWBskTKS1iocIWYmci+iLA== X-Google-Smtp-Source: AGs4zMZtmjkaIihkTlbIWwmdXYG2+PkmVxvNb7RHrqMSH7KXagQGfW7+2r6EuActpr/fWIZ96hYOlw== X-Received: by 10.28.99.139 with SMTP id x133mr491311wmb.122.1510303070897; Fri, 10 Nov 2017 00:37:50 -0800 (PST) Received: from localhost (xd93dd96b.cust.hiper.dk. [217.61.217.107]) by smtp.gmail.com with ESMTPSA id o82sm253166wmo.18.2017.11.10.00.37.49 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 10 Nov 2017 00:37:49 -0800 (PST) Date: Fri, 10 Nov 2017 09:37:55 +0100 From: Christoffer Dall To: Marc Zyngier Cc: Auger Eric , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni Subject: Re: [PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs Message-ID: <20171110083755.GI14144@cbox> References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-17-marc.zyngier@arm.com> <6763d90f-93bf-ddbb-d456-5979b8870aa2@redhat.com> <49bff080-0908-cc7a-7036-543f963180a5@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49bff080-0908-cc7a-7036-543f963180a5@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Nov 08, 2017 at 03:08:36PM +0000, Marc Zyngier wrote: > On 07/11/17 21:28, Auger Eric wrote: > > Hi Marc, > > > > On 27/10/2017 16:28, Marc Zyngier wrote: > >> Upon updating a property, we propagate it all the way to the physical > >> ITS, and ask for an INV command to be executed there. > >> > >> Acked-by: Christoffer Dall > >> Signed-off-by: Marc Zyngier > >> --- > >> virt/kvm/arm/vgic/vgic-its.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > >> index 0b7e648e7a0c..2e77c7c83942 100644 > >> --- a/virt/kvm/arm/vgic/vgic-its.c > >> +++ b/virt/kvm/arm/vgic/vgic-its.c > >> @@ -296,6 +296,9 @@ static int update_lpi_config(struct kvm *kvm, struct vgic_irq *irq, > >> spin_unlock(&irq->irq_lock); > >> } > >> > >> + if (irq->hw) > >> + return its_prop_update_vlpi(irq->host_irq, prop, true); > >> + > >> return 0; > >> } > > I am confused by the vgic_queue_irq_unlock() on the "hw" path. Why is it > > needed in hw mode? > > It's not. I guess we could bypass this altogether and take a short cut > after having updated the priority and enabled fields. > I can apply this on top of the series as well if you're happy with it: commit b54fba93b1330803a59ca75f3a5102e22cadc871 (HEAD -> next-gicv4) Author: Christoffer Dall Date: Fri Nov 10 09:34:54 2017 +0100 KVM: arm/arm64: Don't queue VLPIs on INV/INVALL Since VLPIs are injected directly by the hardware there's no need to mark these as pending in software and queue them on the AP list. Signed-off-by: Christoffer Dall Thanks, -Christoffer Reviewed-by: Marc Zyngier diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c index c93ecd4a903b..a3754ec719c4 100644 --- a/virt/kvm/arm/vgic/vgic-its.c +++ b/virt/kvm/arm/vgic/vgic-its.c @@ -292,11 +292,14 @@ static int update_lpi_config(struct kvm *kvm, struct vgic_irq *irq, irq->priority = LPI_PROP_PRIORITY(prop); irq->enabled = LPI_PROP_ENABLE_BIT(prop); - vgic_queue_irq_unlock(kvm, irq, flags); - } else { - spin_unlock_irqrestore(&irq->irq_lock, flags); + if (!irq->hw) { + vgic_queue_irq_unlock(kvm, irq, flags); + return 0; + } } + spin_unlock_irqrestore(&irq->irq_lock, flags); + if (irq->hw) return its_prop_update_vlpi(irq->host_irq, prop, needs_inv);