From nobody Sat Dec 27 22:53:33 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28990C4332F for ; Thu, 14 Dec 2023 12:14:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1572965AbjLNMOa (ORCPT ); Thu, 14 Dec 2023 07:14:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1572951AbjLNMO2 (ORCPT ); Thu, 14 Dec 2023 07:14:28 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 952EEBD for ; Thu, 14 Dec 2023 04:14:34 -0800 (PST) Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4SrWVm0htSzMnmP; Thu, 14 Dec 2023 20:14:24 +0800 (CST) Received: from kwepemm000007.china.huawei.com (unknown [7.193.23.189]) by mail.maildlp.com (Postfix) with ESMTPS id B818B1404D9; Thu, 14 Dec 2023 20:14:32 +0800 (CST) Received: from [10.174.185.210] (10.174.185.210) by kwepemm000007.china.huawei.com (7.193.23.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 14 Dec 2023 20:14:31 +0800 From: Kunkun Jiang To: Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Jean-Philippe Brucker CC: "moderated list:ARM SMMU DRIVERS" , , open list , "wanghaibin.wang@huawei.com" Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset Message-ID: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com> Date: Thu, 14 Dec 2023 20:13:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [10.174.185.210] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm000007.china.huawei.com (7.193.23.189) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi list, We have observed on GICv4.1 systems that, after a guest reset, the secondary VCPU would receive an IPI_CPU_STOP accidently and failed to come online eventually. | Guest User-space | | reset (with a vSGI pending in the | hardware) [0] | | disable the distributor (write 0 | into GICD_CTLR) [1] | | clear pending status (write 0 into | GICR_ISPENDR0 for each RD) [2] | | disable the distributor (write 0 | into GICD_CTLR) [3] | | enable the distributor with ARE, | Group1 and nASSGIreq [4] The problem is that even if user-space tries to disable the distributor and clear pending bits for all SGIs, we don't actually propogate it into HW (we only record it via vgic_dist->{enabled, nassgireq} and vgic_irq->pending_latch) and the vSGI remains pending across the guest reset. And when we're at [4], all vSGI's vgic_irq->hw are *true* and vgic_v4_enable_vsgis() becomes a nop.. That's not good. The following solution can solve the problem. Not sure if this is a good solution.Sent out early for suggestions or solutions. diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c=20 b/arch/arm64/kvm/vgic/vgic-mmio-v3.c index 89117ba2528a..3678ab33f5b9 100644 Reported-by: Kunkun Jiang Reviewed-by: Zenghui Yu --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c @@ -374,6 +374,10 @@ static int vgic_v3_uaccess_write_pending(struct=20 kvm_vcpu *vcpu, =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 irq->pendin= g_latch =3D true; =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 vgic_queue_= irq_unlock(vcpu->kvm, irq, flags); =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } else { + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (irq->hw && v= gic_irq_is_sgi(irq->intid)) + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 irq_set_irqchip_state(irq->host_irq, + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 IRQCHIP_= STATE_PENDING, + =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 false); =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 irq->pendin= g_latch =3D false; =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 raw_spin_un= lock_irqrestore(&irq->irq_lock, flags); =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 }