Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3140919pxf; Mon, 15 Mar 2021 02:27:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwh8TKINvebAsBWDr7ICf+85IbHoFw3Y3R07bMwxDKlYOeI2VkPQQ6YxbmMhi0xIuSNidrR X-Received: by 2002:aa7:dc49:: with SMTP id g9mr28031915edu.60.1615800433798; Mon, 15 Mar 2021 02:27:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615800433; cv=none; d=google.com; s=arc-20160816; b=cygkUTQ9QTLAwJNiHaZ5VLGKsAABkN5HUuJVp/Owz7WDUsDCETjedzJGq/OH86zqks 8H2TT9tpAOKSZ9Wv2cvHwamAbldU898HhbaKVIO/GRwSxpG/YUPl8MpxG4ums74lFGfT x8mCbCHV0N+lOgHlWZuJ5DoKVFrZpdqidl5Owql5bGbB06HT3DiroXOjjCItsowABilg Eq5YP2LJSD+L3ATl5GtiVTIHhpBNv7r9drMwyJaUnMJ/r6NSfCFyyf8RN5beAB3sq7GL glAbSMUN+wkosoHUAANVY0tV4uVx+6HSPyviGQws00wo8UdmLNSSaYGo6HjiFICKjnaR XTMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=uJAFNY9kR9HBzk4N9NtCu+6fwKX+T+DRn9KcU7JLiTk=; b=i290kzhSyuyQpum6Z4qAWpuHxch8bGKWQgO+xas78tIBy/37sRcEEmSiGllnQjnB21 amuMZeqL2lcAgvDvW7DgNQCV2/bHhgpylSYpVkKMKSNfw1JWVQarTdccnZ3ujwfO0hXW 9jWwsLClLE0lV77/qL1Js/XT9XQbTjsvmn1WA9x3wgyP/M14kQvuMa2RBjK+xfrnZnQC 241fGvNMzDYxv5SWQ5Fp+1dmxJit6LMrtfVw0v2Cy8Yb16pBv7EpsnTXmtQhX5L+2dXb 5cIcFGCUygYrT3ax7KgAlRrPLp1mmVUoZjchohn5J4S4UWYQJ8HCPNfujZpUIT4r1QX8 H3og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ju25si10395379ejc.668.2021.03.15.02.26.51; Mon, 15 Mar 2021 02:27:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229562AbhCOJZy (ORCPT + 99 others); Mon, 15 Mar 2021 05:25:54 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:13954 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229657AbhCOJZf (ORCPT ); Mon, 15 Mar 2021 05:25:35 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DzWF960YzzrWjV; Mon, 15 Mar 2021 17:23:41 +0800 (CST) Received: from [10.174.184.135] (10.174.184.135) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Mon, 15 Mar 2021 17:25:25 +0800 Subject: Re: [PATCH v4 5/6] KVM: arm64: GICv4.1: Restore VLPI pending state to physical side To: Marc Zyngier CC: Eric Auger , Will Deacon , , , , , Alex Williamson , Cornelia Huck , "Lorenzo Pieralisi" , , References: <20210313083900.234-1-lushenming@huawei.com> <20210313083900.234-6-lushenming@huawei.com> <81fbadda-0489-ffc3-cb38-08e89871ec95@huawei.com> From: Shenming Lu Message-ID: Date: Mon, 15 Mar 2021 17:25:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.184.135] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/3/15 17:20, Marc Zyngier wrote: > On 2021-03-15 09:11, Shenming Lu wrote: >> On 2021/3/15 16:30, Marc Zyngier wrote: >>> On 2021-03-13 08:38, Shenming Lu wrote: >>>> From: Zenghui Yu >>>> >>>> When setting the forwarding path of a VLPI (switch to the HW mode), >>>> we can 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 >>>> Signed-off-by: Shenming Lu >>>> --- >>>>  arch/arm64/kvm/vgic/vgic-v4.c | 18 ++++++++++++++++++ >>>>  1 file changed, 18 insertions(+) >>>> >>>> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c >>>> index ac029ba3d337..3b82ab80c2f3 100644 >>>> --- a/arch/arm64/kvm/vgic/vgic-v4.c >>>> +++ b/arch/arm64/kvm/vgic/vgic-v4.c >>>> @@ -449,6 +449,24 @@ 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) { >>>> +        unsigned long flags; >>>> + >>>> +        ret = irq_set_irqchip_state(irq->host_irq, >>>> +                        IRQCHIP_STATE_PENDING, >>>> +                        irq->pending_latch); >>>> +        WARN_RATELIMIT(ret, "IRQ %d", irq->host_irq); >>>> + >>>> +        /* >>>> +         * Clear pending_latch and communicate this state >>>> +         * change via vgic_queue_irq_unlock. >>>> +         */ >>>> +        raw_spin_lock_irqsave(&irq->irq_lock, flags); >>>> +        irq->pending_latch = false; >>>> +        vgic_queue_irq_unlock(kvm, irq, flags); >>>> +    } >>>> + >>>>  out: >>>>      mutex_unlock(&its->its_lock); >>>>      return ret; >>> >>> The read side of the pending state isn't locked, but the write side is. >>> I'd rather you lock the whole sequence for peace of mind. >> >> Did you mean to lock before emitting the mapping request, Or just before reading >> the pending state? > > Just before reading the pending state, so that we can't get a concurrent > modification of that state while we make the interrupt pending in the VPT > and clearing it in the emulation. Get it. I will correct it right now. Thanks, Shenming > > Thanks, > >         M.