Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751353AbdH3LD5 (ORCPT ); Wed, 30 Aug 2017 07:03:57 -0400 Received: from foss.arm.com ([217.140.101.70]:42808 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263AbdH3LD4 (ORCPT ); Wed, 30 Aug 2017 07:03:56 -0400 Subject: Re: [PATCH v3 43/59] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI To: Christoffer Dall Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Christoffer Dall , Thomas Gleixner , Jason Cooper , Eric Auger , Shanker Donthineni , Mark Rutland , Shameerali Kolothum Thodi References: <20170731172637.29355-1-marc.zyngier@arm.com> <20170731172637.29355-44-marc.zyngier@arm.com> <20170828181808.GC24649@cbox> From: Marc Zyngier Organization: ARM Ltd Message-ID: Date: Wed, 30 Aug 2017 12:03:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170828181808.GC24649@cbox> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1142 Lines: 36 On 28/08/17 19:18, Christoffer Dall wrote: > On Mon, Jul 31, 2017 at 06:26:21PM +0100, Marc Zyngier wrote: >> When freeing an LPI (on a DISCARD command, for example), we need >> to unmap the VLPI down to the physical ITS level. >> >> Signed-off-by: Marc Zyngier >> --- >> virt/kvm/arm/vgic/vgic-its.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c >> index 40aeadef33fe..79bac93d3e7d 100644 >> --- a/virt/kvm/arm/vgic/vgic-its.c >> +++ b/virt/kvm/arm/vgic/vgic-its.c >> @@ -623,8 +623,12 @@ static void its_free_ite(struct kvm *kvm, struct its_ite *ite) >> list_del(&ite->ite_list); >> >> /* This put matches the get in vgic_add_lpi. */ >> - if (ite->irq) >> + if (ite->irq) { >> + if (ite->irq->hw) >> + its_unmap_vlpi(ite->irq->host_irq); > > nit: should we raise a warning on a bad return value? I guess we could. Getting an error here is am indication that something has gone wrong... > Otherwise: > > Acked-by: Christoffer Dall Thanks, M. -- Jazz is not dead. It just smells funny...