From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6F880FF885A for ; Tue, 28 Apr 2026 20:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rfkoOBKIj71Ry4HIvc0ePC2zPzNtmJbJhYSXZ/tb0Dg=; b=txyojRONmG3WUUf9o4lqTHp/d6 ZAZyZ23R7KyXZ5BAhlSLvmAO+IGc0VBBZnqDBjdRC7CODf44dohCwISSZdPOsThnLvLe1EDov6mZX JZQd3i7eo1wAkDle+96YPRsRo6fGzKd4tOF4CnRjKZseQn8c1Fwzz5Gg+PXmd9w0FZaCgm+4iRxdo WJ10Bte3OVbNE09JDe+jOjOPfDZH64q36w8DRe1m2xH7HE/nSIQqU+14BBA72lr+Q0vWcyOaQATvV TeQ5vOb5/I9J4psYgBYDMmMTxK0WDGNZlBzjeiZKp8jtTp+ptMfsrgi5aeCvMPw7jswmXp3TomYhq ye+FCd8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHpBx-00000002TDI-2C1Z; Tue, 28 Apr 2026 20:38:01 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHpBv-00000002TCH-0qII for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2026 20:38:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6725F42AE2; Tue, 28 Apr 2026 20:37:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 426A5C2BCAF; Tue, 28 Apr 2026 20:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777408678; bh=V7I0KV6GT9VUys+mlnRoHASgsmtf7Ej4OOFcxCQfZbo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iJ/MtLRuFpFKLhtkCOWoD3zAzpvReiWjXMBOwIVsm17lzf9SW/Xgp7lTGph/unskd 4rTv0Smhfaz3bw45E2MYkMKKmSnFe614l98lfUrdPqtvDgFNCtO160gw56DISDH2CJ o/D3bFAi/3LNG8UOErWmoIUg/avf7OUfppTtolBHW3RK/kTi2pq8wkAofOZN6BKCr1 2lA97PXAj5glaEg9kI7lACoEUwOFCddCimE6V4fIZ1+FittfVRr8EftYm4156n8QUV iZCRXe0YzvrfKUZ+D9snG2v4ojjdBIsdKLRs3faGwTrVa+Zo2/7FugfzgNu9o5juAz f94RT4lu7n3XA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wHpBr-0000000FfsW-3wvY; Tue, 28 Apr 2026 20:37:56 +0000 Date: Tue, 28 Apr 2026 21:37:55 +0100 Message-ID: <87ecjybz30.wl-maz@kernel.org> From: Marc Zyngier To: Vishnu Pajjuri Cc: Fuad Tabba , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Christoffer Dall , Mark Brown , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Darren Hart Subject: Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive In-Reply-To: <87ik9dbys7.wl-maz@kernel.org> References: <20251120172540.2267180-1-maz@kernel.org> <20251120172540.2267180-36-maz@kernel.org> <2e12c5c2-a1b6-47b7-b54c-7281a77bbe0a@os.amperecomputing.com> <878qb9cxzr.wl-maz@kernel.org> <1e050b67-2276-41ad-9265-796ba853dc7c@os.amperecomputing.com> <86a4vo49ni.wl-maz@kernel.org> <86eck71o1v.wl-maz@kernel.org> <861pg213to.wl-maz@kernel.org> <87ik9dbys7.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: vishnu@os.amperecomputing.com, tabba@google.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, christoffer.dall@arm.com, broonie@kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, darren@os.amperecomputing.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260428_133759_278253_8B7C430F X-CRM114-Status: GOOD ( 37.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, 26 Apr 2026 15:07:36 +0100, Marc Zyngier wrote: > > On Sun, 26 Apr 2026 10:14:11 +0100, > Marc Zyngier wrote: > > > > On Wed, 22 Apr 2026 15:57:44 +0100, > > Vishnu Pajjuri wrote: > > > > > > Hi Marc, > > > > > > On 22-04-2026 12:25, Marc Zyngier wrote: > > > > > > > > Have you made progress on this? I can't reproduce it at all despite my > > > > best effort. I'm perfectly happy to help, but you need to give me > > > > *something* to go on. > > > > > > > > > Thanks for your support!! > > > > > > The issue is triggered as soon as the timer interrupt (IRQ 27) is > > > deactivated. Preventing the deactivation of IRQ 27 during nested VGIC > > > state transitions prevents the failure from reproducing. > > > > Which level of deactivation? From L2 to L1? Or L1 to L0? The former > > should just be a an update to the irq structure, while the latter is > > effectively a write to ICC_DIR_EL1, and *that* is a new behaviour > > introduced by this patch. > > > > I wonder if your implementation is such that ICC_DIR_EL1 is trapped by > > ICH_HCR_EL2.TDIR, which is allowed by the architecture, but that none > > of the two implementations I have actually enforce (the trap only > > applies to ICV_DIR_EL1). Can you try the hack below which disables the > > traps much earlier, and let me know if that helps? > > > > Even if that's the case, this should result in an EL2->EL2 exception, > > and that should be caught as an unhandled exception in entry-common.c, > > so something else is afoot. > > Actually, this should never happen. ICH_HCR_EL2.TDIR is constructed > like all the other GICv3 trap bits, in the sense that it only traps > accesses from EL1, not EL2 (for sanity reasons, I'm not considering > the possibility of a trap to EL3...). > > Still, I'm interested in finding out if that hack helps at all. Any update? I've been racking my brain on this one, and I may have another potential avenue to explore. Does your CPU implement SEIS (ICC_CTLR_EL1.SEIS == 1)? I think there is a corner case where we can end-up doing a double deactivation. On its own, that's a completely harmless thing to do. Except on an implementation with SEIS, which could deliver an SError and route that to EL3. Add quality firmware to the mix, and you could be in for a treat. Obviously, implementing SEIS is a terrible and pointless thing to do (it's been long deprecated), but in case someone felt adventurous in the RTL department, let me know what the following hack does for you. M. diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c index 9e841e7afd4a7..c92ca6969e85f 100644 --- a/arch/arm64/kvm/vgic/vgic-v3.c +++ b/arch/arm64/kvm/vgic/vgic-v3.c @@ -275,7 +275,7 @@ void vgic_v3_deactivate(struct kvm_vcpu *vcpu, u64 val) lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT; } - if (lr & ICH_LR_HW) + if ((lr & ICH_LR_HW) && !vgic_state_is_nested(vcpu)) vgic_v3_deactivate_phys(FIELD_GET(ICH_LR_PHYS_ID_MASK, lr)); vgic_v3_fold_lr(vcpu, lr); -- Jazz isn't dead. It just smells funny.