From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933733AbdKGVBs (ORCPT ); Tue, 7 Nov 2017 16:01:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49760 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933563AbdKGVBr (ORCPT ); Tue, 7 Nov 2017 16:01:47 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 909D27E42A Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-14-marc.zyngier@arm.com> Cc: Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni From: Auger Eric Message-ID: <52c64fa1-f662-2703-53c5-d2024ef12254@redhat.com> Date: Tue, 7 Nov 2017 22:01:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171027142855.21584-14-marc.zyngier@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 07 Nov 2017 21:01:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > When the guest issues an affinity change, we need to tell the physical > ITS that we're now targetting a new vcpu. This is done by extracting > the current mapping, updating the target, and reapplying the mapping. > > Reviewed-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-its.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index c9b1c0967426..42ffb9084bb7 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, u32 **intid_ptr) > > static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu) > { > + int ret = 0; > + > spin_lock(&irq->irq_lock); > irq->target_vcpu = vcpu; > spin_unlock(&irq->irq_lock); > > - return 0; > + if (irq->hw) { > + struct its_vlpi_map map; > + > + ret = its_get_vlpi(irq->host_irq, &map); > + if (ret) > + return ret; > + > + map.vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; > + > + ret = its_map_vlpi(irq->host_irq, &map); Do we check somewhere the virtual LPI ID does not exceed the capacity of the VPT. I fail to find that in the irq-gic-v3-its.c driver. Also in case the hw part fails, should we still have the irq->target_cpu set to the new value. In other words shouldn't we first do the hw block and upon success set the target_vcpu? Thanks Eric > + } > + > + return ret; > } > > /* > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Auger Eric Subject: Re: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS Date: Tue, 7 Nov 2017 22:01:41 +0100 Message-ID: <52c64fa1-f662-2703-53c5-d2024ef12254@redhat.com> References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-14-marc.zyngier@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: In-Reply-To: <20171027142855.21584-14-marc.zyngier@arm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > When the guest issues an affinity change, we need to tell the physical > ITS that we're now targetting a new vcpu. This is done by extracting > the current mapping, updating the target, and reapplying the mapping. > > Reviewed-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-its.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index c9b1c0967426..42ffb9084bb7 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, u32 **intid_ptr) > > static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu) > { > + int ret = 0; > + > spin_lock(&irq->irq_lock); > irq->target_vcpu = vcpu; > spin_unlock(&irq->irq_lock); > > - return 0; > + if (irq->hw) { > + struct its_vlpi_map map; > + > + ret = its_get_vlpi(irq->host_irq, &map); > + if (ret) > + return ret; > + > + map.vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; > + > + ret = its_map_vlpi(irq->host_irq, &map); Do we check somewhere the virtual LPI ID does not exceed the capacity of the VPT. I fail to find that in the irq-gic-v3-its.c driver. Also in case the hw part fails, should we still have the irq->target_cpu set to the new value. In other words shouldn't we first do the hw block and upon success set the target_vcpu? Thanks Eric > + } > + > + return ret; > } > > /* > From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@redhat.com (Auger Eric) Date: Tue, 7 Nov 2017 22:01:41 +0100 Subject: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS In-Reply-To: <20171027142855.21584-14-marc.zyngier@arm.com> References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-14-marc.zyngier@arm.com> Message-ID: <52c64fa1-f662-2703-53c5-d2024ef12254@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > When the guest issues an affinity change, we need to tell the physical > ITS that we're now targetting a new vcpu. This is done by extracting > the current mapping, updating the target, and reapplying the mapping. > > Reviewed-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-its.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index c9b1c0967426..42ffb9084bb7 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, u32 **intid_ptr) > > static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu) > { > + int ret = 0; > + > spin_lock(&irq->irq_lock); > irq->target_vcpu = vcpu; > spin_unlock(&irq->irq_lock); > > - return 0; > + if (irq->hw) { > + struct its_vlpi_map map; > + > + ret = its_get_vlpi(irq->host_irq, &map); > + if (ret) > + return ret; > + > + map.vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; > + > + ret = its_map_vlpi(irq->host_irq, &map); Do we check somewhere the virtual LPI ID does not exceed the capacity of the VPT. I fail to find that in the irq-gic-v3-its.c driver. Also in case the hw part fails, should we still have the irq->target_cpu set to the new value. In other words shouldn't we first do the hw block and upon success set the target_vcpu? Thanks Eric > + } > + > + return ret; > } > > /* >