Re: [PATCH v3 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side

From: Marc Zyngier <maz@kernel.org>
To: Shenming Lu <lushenming@huawei.com>
Cc: Eric Auger <eric.auger@redhat.com>,
	"Will\ Deacon" <will@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<kvmarm@lists.cs.columbia.edu>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>
Subject: Re: [PATCH v3 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side
Date: Thu, 11 Mar 2021 09:14:16 +0000	[thread overview]
Message-ID: <87tupif3x3.wl-maz@kernel.org> (raw)
In-Reply-To: <20210127121337.1092-4-lushenming@huawei.com>

On Wed, 27 Jan 2021 12:13:36 +0000,
Shenming Lu <lushenming@huawei.com> wrote:
> 
> From: Zenghui Yu <yuzenghui@huawei.com>
> 
> When setting the forwarding path of a VLPI (switch to the HW mode),
> we could also transfer the pending state from irq->pending_latch to
> VPT (especially in migration, the pending states of VLPIs are restored
> into kvm’s vgic first). And we currently send "INT+VSYNC" to trigger
> a VLPI to pending.
> 
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> Signed-off-by: Shenming Lu <lushenming@huawei.com>
> ---
>  arch/arm64/kvm/vgic/vgic-v4.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
> index ac029ba3d337..a3542af6f04a 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -449,6 +449,20 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int virq,
>  	irq->host_irq	= virq;
>  	atomic_inc(&map.vpe->vlpi_count);
>  
> +	/* Transfer pending state */
> +	if (irq->pending_latch) {
> +		ret = irq_set_irqchip_state(irq->host_irq,
> +					    IRQCHIP_STATE_PENDING,
> +					    irq->pending_latch);
> +		WARN_RATELIMIT(ret, "IRQ %d", irq->host_irq);
> +
> +		/*
> +		 * Let it be pruned from ap_list later and don't bother
> +		 * the List Register.
> +		 */
> +		irq->pending_latch = false;

NAK. If the interrupt is on the AP list, it must be pruned from it
*immediately*. The only case where it can be !pending and still on the
AP list is in interval between sync and prune. If we start messing
with this, we can't reason about the state of this list anymore.

Consider calling vgic_queue_irq_unlock() here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel