From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932952AbdKGUPk (ORCPT ); Tue, 7 Nov 2017 15:15:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51014 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932904AbdKGUPf (ORCPT ); Tue, 7 Nov 2017 15:15:35 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2F017C04B927 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI 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-12-marc.zyngier@arm.com> Cc: Christoffer Dall , Shanker Donthineni , Mark Rutland , Shameerali Kolothum Thodi , Andre Przywara , Christoffer Dall From: Auger Eric Message-ID: <6e12eac9-7b75-2c2c-0c79-d17a3c0d65eb@redhat.com> Date: Tue, 7 Nov 2017 21:15:29 +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-12-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.31]); Tue, 07 Nov 2017 20:15:35 +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: > If the guest issues an INT command targetting a VLPI, let's > call into the irq_set_irqchip_state() helper to make it pending > on the physical side. > > This works just as well if userspace decides to inject an interrupt > using the normal userspace API... There is also another path: KVM_SIGNAL_MSI ioctl / kvm_send_userspace_msi / kvm_set_msi / vgic_its_inject_msi / vgic_its_trigger_msi I wonder whether we shouldn't prevent the userspace from messing up with the host irq pending state? Thanks Eric > > Acked-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-its.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index 89768d2b6a91..b2a678d131d0 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -578,6 +578,10 @@ static int vgic_its_trigger_msi(struct kvm *kvm, struct vgic_its *its, > if (err) > return err; > > + if (irq->hw) > + return irq_set_irqchip_state(irq->host_irq, > + IRQCHIP_STATE_PENDING, true); > + > spin_lock(&irq->irq_lock); > irq->pending_latch = true; > vgic_queue_irq_unlock(kvm, irq); >