Message ID | 20231213061610.11100-1-yongxuan.wang@sifive.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp7576972dys; Tue, 12 Dec 2023 22:16:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IHH9B27PetS1MwcJGiIGAl2+6STtJ9nhtNU6PrpwhaGno5evS0ju+8A3+HxSTWAenbcpXPY X-Received: by 2002:a05:6808:1185:b0:3b9:e7ee:4973 with SMTP id j5-20020a056808118500b003b9e7ee4973mr9101271oil.108.1702448191979; Tue, 12 Dec 2023 22:16:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702448191; cv=none; d=google.com; s=arc-20160816; b=CgNkXKDwdp0+vAL+G6VK6oywqfjI+HMOCVa/2O+hvDRUDGQJpDLMGrp1MX/xx1Z5Z7 ethmDrIZBR+c7A0xv3sDisbdi9CkMYR/Buiu3iImYJvn8Ge37xaJ22MPlvzTxKWJyCbn Argi/PDeHFAztHioBpAdIusxU8xoyHgb5r0JW0gXcK2IKYqPEfggq+NJ2CgGtins2moE j5ka5sdwQI+fHqLmAxWDV1bnK4e4eSj6tB+8OkbHReRny5w8pRwmI5i8TtlSO9/5ITOf 8Ig+wdPpOcKVXr4DuA3fW5WfWqazlio9Rz+pYPSj7CQB1b4Ph/kI1i45SCU6BfqQjwtI sDQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=uvNv5wfHF4xhsTtKWQpkLRjgdWBIUIRMHOfm0nTFkAs=; fh=pAePdAqvH+3TdmAUooWVcKmfuUnPgRehWFosKZt7P70=; b=eFjRihcXPKgwiQRyLmyMwoU8XrhJ3ePcAoMXU3CMO+wiesUIhP/Xkg9nkpJShwyBFw I3YKxwxW6dXwnj0WDmohLJmhMotmLPuY/k2hdRTf8un0BODpRgnNHxBKG81Y+sGy3+2z jMqcKllxvaPuiW7LszAssHBRStqgDDHFk99emBHgMTTlShusFQviJhRchWtwyMUhTaOU 9Ua7th+NleznUdsiMNS9X6Xl2DSoDbDte0hIk2uVIFRtXoiZmrUyyFi5Nnrm2BHl7RdD gfHJivQxaY048iNFvgLzMJgN4YSU4lXvUHVxjCbqeFjdipldHcU6jZSiskaBPyuwLUoS 3H0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=Igxe7+XE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id x19-20020a17090a8a9300b00288654f292esi9133876pjn.20.2023.12.12.22.16.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 22:16:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=Igxe7+XE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 9A1118027B72; Tue, 12 Dec 2023 22:16:28 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378558AbjLMGQM (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 13 Dec 2023 01:16:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233139AbjLMGQK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Dec 2023 01:16:10 -0500 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE32DE3 for <linux-kernel@vger.kernel.org>; Tue, 12 Dec 2023 22:16:16 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3b8b8372e30so4905548b6e.3 for <linux-kernel@vger.kernel.org>; Tue, 12 Dec 2023 22:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1702448176; x=1703052976; darn=vger.kernel.org; h=message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uvNv5wfHF4xhsTtKWQpkLRjgdWBIUIRMHOfm0nTFkAs=; b=Igxe7+XErz0OpoPk/X2UUroCzmLxq0eraYDWHPJe2KaVNQ6dWfFphGgBafPBeeAjMV 3d3NUNVMPWyi7wlitNCoe3lH8VCPMxNUNkabFDz6ZK1zRB7hJjc3KFsAOizhJGp8ISHJ XRhifwLqSgRLoZDcma9TUX0KVgSwp8YV0Z7zC7muAdthhvG058jPM43Utex7KUAukAyI 3+ae72ojMj/zRFsQ4Rm9bxRrrSi1ZUZSvvCuX9ENd4orDS3UOucdXjzjKjdePhMsVZ8u M/YC2cbjYG2G7AzTxb9xJhHX2NwKd0H98xe5FP5ukIsAYUpQSB42Nh6jjCsmpWEFaAnj uJMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702448176; x=1703052976; h=message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uvNv5wfHF4xhsTtKWQpkLRjgdWBIUIRMHOfm0nTFkAs=; b=Nbs83sl0TLWWYOi3eKifAqvIRs622lQcvLFk7nBhfp9X1wvmMo6CmZA/Kp0YyfPEOU gp1D/lnDMu+c929U0x3fGeYzt5aLPgzmbevJu9lAeZ1f9AGHVa1vy3CNb7KqshSibHNn 11/STa01riKB9MG/VAKf/80RNNleMDIZ06SmjaiypdXVrxWPFYqsMbkdM9aSY4ik24nK GaDivhMJVuVGcpEYpDhf4NpWgTN1mwXd6JmUFU87ivO8ZZBHWEbanzrZHOJM6q0wtqKM dkVyMvCEnipv0LLcMj/pbAre+wcy1lNaGbsP+sWtMu0vtv8poSOT0givseHdhCg6lz/+ K90g== X-Gm-Message-State: AOJu0Yz513BU0jc9AXBW1hJti/QS9Cpnrgi1RmMpU9ZmBUI5GOnP35G1 1/Y8Y1QbFHH7FfqUAzSOIxZ0XA== X-Received: by 2002:a05:6808:1385:b0:3b8:45cf:9b2 with SMTP id c5-20020a056808138500b003b845cf09b2mr9139581oiw.20.1702448175749; Tue, 12 Dec 2023 22:16:15 -0800 (PST) Received: from hsinchu26.internal.sifive.com (59-124-168-89.hinet-ip.hinet.net. [59.124.168.89]) by smtp.gmail.com with ESMTPSA id w2-20020a654102000000b005c65ed23b65sm7731076pgp.94.2023.12.12.22.16.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 22:16:14 -0800 (PST) From: Yong-Xuan Wang <yongxuan.wang@sifive.com> To: linux-riscv@lists.infradead.org, kvm-riscv@lists.infradead.org Cc: greentime.hu@sifive.com, vincent.chen@sifive.com, Yong-Xuan Wang <yongxuan.wang@sifive.com>, Anup Patel <anup@brainfault.org>, Atish Patra <atishp@atishpatra.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/1] RISCV: KVM: update external interrupt atomically for IMSIC swfile Date: Wed, 13 Dec 2023 06:16:09 +0000 Message-Id: <20231213061610.11100-1-yongxuan.wang@sifive.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 12 Dec 2023 22:16:28 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785146315233214206 X-GMAIL-MSGID: 1785146315233214206 |
Series |
[v2,1/1] RISCV: KVM: update external interrupt atomically for IMSIC swfile
|
|
Commit Message
Yong-Xuan Wang
Dec. 13, 2023, 6:16 a.m. UTC
The emulated IMSIC update the external interrupt pending depending on the value of eidelivery and topei. It might lose an interrupt when it is interrupted before setting the new value to the pending status. For example, when VCPU0 sends an IPI to VCPU1 via IMSIC: VCPU0 VCPU1 CSRSWAP topei = 0 The VCPU1 has claimed all the external interrupt in its interrupt handler. topei of VCPU1's IMSIC = 0 set pending in VCPU1's IMSIC topei of VCPU1' IMSIC = 1 set the external interrupt pending of VCPU1 clear the external interrupt pending of VCPU1 When the VCPU1 switches back to VS mode, it exits the interrupt handler because the result of CSRSWAP topei is 0. If there are no other external interrupts injected into the VCPU1's IMSIC, VCPU1 will never know this pending interrupt unless it initiative read the topei. If the interruption occurs between updating interrupt pending in IMSIC and updating external interrupt pending of VCPU, it will not cause a problem. Suppose that the VCPU1 clears the IPI pending in IMSIC right after VCPU0 sets the pending, the external interrupt pending of VCPU1 will not be set because the topei is 0. But when the VCPU1 goes back to VS mode, the pending IPI will be reported by the CSRSWAP topei, it will not lose this interrupt. So we only need to make the external interrupt updating procedure as a critical section to avoid the problem. Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC") Tested-by: Roy Lin <roy.lin@sifive.com> Tested-by: Wayling Chen <wayling.chen@sifive.com> Co-developed-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> --- Changelog v2: - rename the variable and add a short comment in the code --- arch/riscv/kvm/aia_imsic.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Comments
On Wed, Dec 13, 2023 at 11:46 AM Yong-Xuan Wang <yongxuan.wang@sifive.com> wrote: > > The emulated IMSIC update the external interrupt pending depending on the > value of eidelivery and topei. It might lose an interrupt when it is > interrupted before setting the new value to the pending status. > > For example, when VCPU0 sends an IPI to VCPU1 via IMSIC: > > VCPU0 VCPU1 > > CSRSWAP topei = 0 > The VCPU1 has claimed all the external > interrupt in its interrupt handler. > > topei of VCPU1's IMSIC = 0 > > set pending in VCPU1's IMSIC > > topei of VCPU1' IMSIC = 1 > > set the external interrupt > pending of VCPU1 > > clear the external interrupt pending > of VCPU1 > > When the VCPU1 switches back to VS mode, it exits the interrupt handler > because the result of CSRSWAP topei is 0. If there are no other external > interrupts injected into the VCPU1's IMSIC, VCPU1 will never know this > pending interrupt unless it initiative read the topei. > > If the interruption occurs between updating interrupt pending in IMSIC > and updating external interrupt pending of VCPU, it will not cause a > problem. Suppose that the VCPU1 clears the IPI pending in IMSIC right > after VCPU0 sets the pending, the external interrupt pending of VCPU1 > will not be set because the topei is 0. But when the VCPU1 goes back to > VS mode, the pending IPI will be reported by the CSRSWAP topei, it will > not lose this interrupt. > > So we only need to make the external interrupt updating procedure as a > critical section to avoid the problem. > > Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC") > Tested-by: Roy Lin <roy.lin@sifive.com> > Tested-by: Wayling Chen <wayling.chen@sifive.com> > Co-developed-by: Vincent Chen <vincent.chen@sifive.com> > Signed-off-by: Vincent Chen <vincent.chen@sifive.com> > Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Queued as fixes for Linux-6.7 Thanks, Anup > --- > Changelog > v2: > - rename the variable and add a short comment in the code > --- > arch/riscv/kvm/aia_imsic.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c > index 6cf23b8adb71..e808723a85f1 100644 > --- a/arch/riscv/kvm/aia_imsic.c > +++ b/arch/riscv/kvm/aia_imsic.c > @@ -55,6 +55,7 @@ struct imsic { > /* IMSIC SW-file */ > struct imsic_mrif *swfile; > phys_addr_t swfile_pa; > + spinlock_t swfile_extirq_lock; > }; > > #define imsic_vs_csr_read(__c) \ > @@ -613,12 +614,23 @@ static void imsic_swfile_extirq_update(struct kvm_vcpu *vcpu) > { > struct imsic *imsic = vcpu->arch.aia_context.imsic_state; > struct imsic_mrif *mrif = imsic->swfile; > + unsigned long flags; > + > + /* > + * The critical section is necessary during external interrupt > + * updates to avoid the risk of losing interrupts due to potential > + * interruptions between reading topei and updating pending status. > + */ > + > + spin_lock_irqsave(&imsic->swfile_extirq_lock, flags); > > if (imsic_mrif_atomic_read(mrif, &mrif->eidelivery) && > imsic_mrif_topei(mrif, imsic->nr_eix, imsic->nr_msis)) > kvm_riscv_vcpu_set_interrupt(vcpu, IRQ_VS_EXT); > else > kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_EXT); > + > + spin_unlock_irqrestore(&imsic->swfile_extirq_lock, flags); > } > > static void imsic_swfile_read(struct kvm_vcpu *vcpu, bool clear, > @@ -1039,6 +1051,7 @@ int kvm_riscv_vcpu_aia_imsic_init(struct kvm_vcpu *vcpu) > } > imsic->swfile = page_to_virt(swfile_page); > imsic->swfile_pa = page_to_phys(swfile_page); > + spin_lock_init(&imsic->swfile_extirq_lock); > > /* Setup IO device */ > kvm_iodevice_init(&imsic->iodev, &imsic_iodoev_ops); > -- > 2.17.1 >
diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c index 6cf23b8adb71..e808723a85f1 100644 --- a/arch/riscv/kvm/aia_imsic.c +++ b/arch/riscv/kvm/aia_imsic.c @@ -55,6 +55,7 @@ struct imsic { /* IMSIC SW-file */ struct imsic_mrif *swfile; phys_addr_t swfile_pa; + spinlock_t swfile_extirq_lock; }; #define imsic_vs_csr_read(__c) \ @@ -613,12 +614,23 @@ static void imsic_swfile_extirq_update(struct kvm_vcpu *vcpu) { struct imsic *imsic = vcpu->arch.aia_context.imsic_state; struct imsic_mrif *mrif = imsic->swfile; + unsigned long flags; + + /* + * The critical section is necessary during external interrupt + * updates to avoid the risk of losing interrupts due to potential + * interruptions between reading topei and updating pending status. + */ + + spin_lock_irqsave(&imsic->swfile_extirq_lock, flags); if (imsic_mrif_atomic_read(mrif, &mrif->eidelivery) && imsic_mrif_topei(mrif, imsic->nr_eix, imsic->nr_msis)) kvm_riscv_vcpu_set_interrupt(vcpu, IRQ_VS_EXT); else kvm_riscv_vcpu_unset_interrupt(vcpu, IRQ_VS_EXT); + + spin_unlock_irqrestore(&imsic->swfile_extirq_lock, flags); } static void imsic_swfile_read(struct kvm_vcpu *vcpu, bool clear, @@ -1039,6 +1051,7 @@ int kvm_riscv_vcpu_aia_imsic_init(struct kvm_vcpu *vcpu) } imsic->swfile = page_to_virt(swfile_page); imsic->swfile_pa = page_to_phys(swfile_page); + spin_lock_init(&imsic->swfile_extirq_lock); /* Setup IO device */ kvm_iodevice_init(&imsic->iodev, &imsic_iodoev_ops);