From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 307781ACEDE; Wed, 4 Mar 2026 09:35:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772616933; cv=none; b=NNodN0M2/+8jgVN2MlIE8Q7oyDwUxQKncHm/Diycvb3JxXNwYPn7v+MnNuuj1clJ/2H1Q+IPA48LXcncqfVou53pXspnYDoLxu8v1EmZYOdVWREpAa7AuMCB0XdPvaiGu1Gkv3WoAVRMjdbix3D1lWDby3mIb5ykIrcwU+3Ogw4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772616933; c=relaxed/simple; bh=fcQPpx8aXl/bNZmJJr4UNqNuegofLcCcrPHmWDmwHeM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=K1K73O1ZtW8X0M86LcwYpGEwz8YWNrSsAsTW4FNcDwIMEBjhMP3jJ21eg/JhZGr9U81ct8Tj29djM3DyUljkouCD9h5QqEm1jh1LZUeAQskslikj8klEdtrYawOv16auSnwPaDut5+WoyYaxGBfFC5Z6640W4xYSOX6yY7v29oE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jAAAOGE3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jAAAOGE3" 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) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.