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 1AEC7EB7EB5 for ; Wed, 4 Mar 2026 09:35:41 +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=djsTcbBZjIyNntDpdOqovGkZ3lMCp0FX3FUDPF5jHto=; b=y3Ifbp51Kyq+IpfzZdfJY+4jlo cKbTqVrq0vLEA9KzR/tsEPvPgabfNs5adoi5xaBJ7eV1w6p8aALMdQiWjXP+Nw/J8jtyT99+bbIyR K/8iFoCODromj+YIniYCr79VlVwALofVhpHq5rIgydmfC7oI8a9I0BOmWlQm3hoMnpoZ80oSvdFpM qKzv6PrRmw6Mw48AJrba6L+Sqdh3V1UZVe8hJrcp7ztAPmRwJ3aA+PvJL40A+qfx5ppBqIwONzMNP Qp3+0/Yr07ngXQES2a9UMPe0AD83JV8dD+deYUVCHswJBM0vvOrFcATVvt8rXPeEieWeUbiM7W6Yq kRK6oV4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vxidj-0000000Gt6V-3aL1; Wed, 04 Mar 2026 09:35:35 +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 1vxidh-0000000Gt5H-3jsl for linux-arm-kernel@lists.infradead.org; Wed, 04 Mar 2026 09:35:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 29C77408A7; Wed, 4 Mar 2026 09:35:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3771C19423; Wed, 4 Mar 2026 09:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772616933; bh=fcQPpx8aXl/bNZmJJr4UNqNuegofLcCcrPHmWDmwHeM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jAAAOGE3yEaLrrLntuxDP4H0mebq4t+SmQ5VHnBBo3slVvJte1dhqls/6yLwgccPj JGhp+O05g7UxK+18O7ErIEpLcfmVlKe3YaD2LSycrMQs/h8/FGkJSL/uC25dYkS1hd 0mEB9FT6J1C/tStohhvhX07snjfQp79h8RsKwhD+J2EJ9bX+E6jaAojpDX0ayG+j24 94Bg4T+9U1Tt+NXm8oRxArfvm/PXDREZWT02eOEpUU361uHOF3TF9eTLKMMBtO8dDD AvOc3HHq3RJ4nUW5QtJrnV/sfO+AU+2XzFeLUHzUDeed9X83iE9epPg8dJfI+xX75K W6qVuInzp8ABg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1vxide-0000000FyTI-31HL; Wed, 04 Mar 2026 09:35:30 +0000 Date: Wed, 04 Mar 2026 09:35:30 +0000 Message-ID: <864imw7x99.wl-maz@kernel.org> From: Marc Zyngier To: Sascha Bischoff Cc: "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , nd , "oliver.upton@linux.dev" , Joey Gouly , Suzuki Poulose , "yuzenghui@huawei.com" , "peter.maydell@linaro.org" , "lpieralisi@kernel.org" , Timothy Hayes , "jonathan.cameron@huawei.com" Subject: Re: [PATCH v5 16/36] KVM: arm64: gic-v5: Implement direct injection of PPIs In-Reply-To: <20260226155515.1164292-17-sascha.bischoff@arm.com> References: <20260226155515.1164292-1-sascha.bischoff@arm.com> <20260226155515.1164292-17-sascha.bischoff@arm.com> 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: Sascha.Bischoff@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, nd@arm.com, oliver.upton@linux.dev, Joey.Gouly@arm.com, Suzuki.Poulose@arm.com, yuzenghui@huawei.com, peter.maydell@linaro.org, lpieralisi@kernel.org, Timothy.Hayes@arm.com, jonathan.cameron@huawei.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-20260304_013533_969871_402CB080 X-CRM114-Status: GOOD ( 36.70 ) 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 Thu, 26 Feb 2026 15:59:33 +0000, Sascha Bischoff wrote: > > GICv5 is able to directly inject PPI pending state into a guest using > a mechanism called DVI whereby the pending bit for a paticular PPI is > driven directly by the physically-connected hardware. This mechanism > itself doesn't allow for any ID translation, so the host interrupt is > directly mapped into a guest with the same interrupt ID. > > When mapping a virtual interrupt to a physical interrupt via > kvm_vgic_map_irq for a GICv5 guest, check if the interrupt itself is a > PPI or not. If it is, and the host's interrupt ID matches that used > for the guest DVI is enabled, and the interrupt itself is marked as > directly_injected. > > When the interrupt is unmapped again, this process is reversed, and > DVI is disabled for the interrupt again. > > Note: the expectation is that a directly injected PPI is disabled on > the host while the guest state is loaded. The reason is that although > DVI is enabled to drive the guest's pending state directly, the host > pending state also remains driven. In order to avoid the same PPI > firing on both the host and the guest, the host's interrupt must be > disabled (masked). This is left up to the code that owns the device > generating the PPI as this needs to be handled on a per-VM basis. One > VM might use DVI, while another might not, in which case the physical > PPI should be enabled for the latter. > > Co-authored-by: Timothy Hayes > Signed-off-by: Timothy Hayes > Signed-off-by: Sascha Bischoff > Reviewed-by: Jonathan Cameron > --- > arch/arm64/kvm/vgic/vgic-v5.c | 15 +++++++++++++++ > arch/arm64/kvm/vgic/vgic.c | 10 ++++++++++ > arch/arm64/kvm/vgic/vgic.h | 1 + > include/kvm/arm_vgic.h | 1 + > 4 files changed, 27 insertions(+) > > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c > index 5b35c756887a9..f5cd9decfc26e 100644 > --- a/arch/arm64/kvm/vgic/vgic-v5.c > +++ b/arch/arm64/kvm/vgic/vgic-v5.c > @@ -86,6 +86,21 @@ int vgic_v5_probe(const struct gic_kvm_info *info) > return 0; > } > > +/* > + * Sets/clears the corresponding bit in the ICH_PPI_DVIR register. > + */ > +int vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, u32 irq, bool dvi) > +{ > + struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5; > + u32 ppi = FIELD_GET(GICV5_HWIRQ_ID, irq); > + unsigned long *p; > + > + p = (unsigned long *)&cpu_if->vgic_ppi_dvir[ppi / 64]; > + __assign_bit(ppi % 64, p, dvi); > + > + return 0; > +} > + > void vgic_v5_load(struct kvm_vcpu *vcpu) > { > struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5; > diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c > index 1005ff5f36235..62e58fdf611d3 100644 > --- a/arch/arm64/kvm/vgic/vgic.c > +++ b/arch/arm64/kvm/vgic/vgic.c > @@ -577,12 +577,22 @@ static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq, > irq->host_irq = host_irq; > irq->hwintid = data->hwirq; > irq->ops = ops; > + > + if (vgic_is_v5(vcpu->kvm) && > + __irq_is_ppi(KVM_DEV_TYPE_ARM_VGIC_V5, irq->intid)) > + irq->directly_injected = !vgic_v5_set_ppi_dvi(vcpu, irq->hwintid, > + true); > + Huh. A couple of things here: - under what conditions would irq->directly_injected not be set to true for a PPI? That can never happen here AFAICT. - we have per-IRQ operations, and PPIs do have such ops attached to them. Why can't this be moved to such a callback? > return 0; > } > > /* @irq->irq_lock must be held */ > static inline void kvm_vgic_unmap_irq(struct vgic_irq *irq) > { > + if (irq->directly_injected && vgic_is_v5(irq->target_vcpu->kvm)) > + WARN_ON(vgic_v5_set_ppi_dvi(irq->target_vcpu, irq->hwintid, false)); > + > + irq->directly_injected = false; > irq->hw = false; > irq->hwintid = 0; > irq->ops = NULL; > diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h > index 81d464d26534f..d7fe867a27b64 100644 > --- a/arch/arm64/kvm/vgic/vgic.h > +++ b/arch/arm64/kvm/vgic/vgic.h > @@ -364,6 +364,7 @@ void vgic_debug_init(struct kvm *kvm); > void vgic_debug_destroy(struct kvm *kvm); > > int vgic_v5_probe(const struct gic_kvm_info *info); > +int vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, u32 irq, bool dvi); Doing the above would keep these things private to the vgic-v5 implementation. Thanks, M. -- Without deviation from the norm, progress is not possible.