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 B3848FF885A for ; Tue, 28 Apr 2026 16:41:04 +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=zpKLL97s1k57zOX2kX+MMTv+yE0HENem3+DX7eclyDc=; b=cWDUGDIjQE/lYelS02DnjglUvh cIEfwHmqKM72jeLDfDRfmtFGKbrAYi4YrnHXcJeYQS6EMcx2ozb7DFIs56ZLfXeAwcihTfNgtAPyE TxyWcc2+ifkBrn6lQFP+UR8U/OA1BsFeMm3fdSGUtoa+IZ/QYXuAXmDds3e4LD30edwIcS2K/2JGe We+7C09RAh8x3iNQLw0GgSwVHqCVh9Di25fbzafusNkpHLbYzzA9AczhlFzF41eWF8+BiVUVM7sC/ X5GmoLp8DBNqUg1uCyi7pzg5ourgrY2ULGnCo9Ao6xPHPFldu2cs9h9ILd5MYfWOJGuJfftSg3YTT PGT/8yZg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHlUY-00000001xsd-2Gnq; Tue, 28 Apr 2026 16:40:58 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHlUX-00000001xsR-3AZu for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2026 16:40:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id EC06260008; Tue, 28 Apr 2026 16:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97051C2BCAF; Tue, 28 Apr 2026 16:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777394456; bh=ZAspeRQpPs/vaebT+xzsMbjuhXb3xNX22pJl6stbWDA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sxfqcIApUyYsWistFCrBLd9QTLKDkKOvTn3RdTUl3kjMNi1qhtGnxGLr91D9JyBz1 l4gznvyNDfYWEC//aTJEC0FvuaQbZSXJtoCD5seIPn42MUeZ6Pz8WGA0zsXc8BNZFV n9c91AtT2i2yvFPRSE49hG89u42PVMPJ4/cn09MgLepVdYtSlehgB2VAror+E1S3wh 0lRTrm0h01F7KvcuM1oZESH/27Fadct7uACVQUnowlCKLFZATCrTauXijMmeVjugzr 8C2fkvVzwewJ075tysgn/Ioc2DlP1+63Blom0J4dBnNoIdQsRgHjS36xpkYIhgsOJE sfKbe9kTrWR9Q== 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 1wHlUU-0000000FbYc-1IMf; Tue, 28 Apr 2026 16:40:54 +0000 Date: Tue, 28 Apr 2026 17:40:53 +0100 Message-ID: <86o6j3yr56.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 Subject: Re: [PATCH 06/43] KVM: arm64: gic-v5: Add VPE doorbell domain In-Reply-To: <20260427160547.3129448-7-sascha.bischoff@arm.com> References: <20260427160547.3129448-1-sascha.bischoff@arm.com> <20260427160547.3129448-7-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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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 Mon, 27 Apr 2026 17:08:05 +0100, Sascha Bischoff wrote: > > GICv5 supports two types of doorbell - VPE doorbells and VM > doorbells. In KVM we only support Targeted interrupts, and do not > support 1ofN target selection. This means that we only implement VPE > doorbells. These doorbells are implemented as host LPIs which are > generated when a non-resident VPE has a pending interrupt of > sufficient priority and the doorbell has been requested as part of > making the VPE non-resident. This is mostly a repeat of the architecture spec. I don't think we need to paraphrase it. > > VPE doorbells allow KVM to wake VPEs (so, vcpus) as soon as the > hardware determines that sufficient conditions for the interrupt to be > signalled have been met. This simplifies the wake-up path for vcpus > with GICv5 for LPIs and SPIs. NOTE: PPI pending state must still be > checked explicitly as the IRS never sees them. Drop the note, it serves no purpose here. > > This change introduces support for the vgic_v5 doorbell domain. One > doorbell domain is created per GICv5 VM, and all VPEs have their own > doorbell within this domain. When the doorbell fires, this is tracked > (in gicv5_vpe.db_fired) and the corresponding vcpu is kicked. > > Signed-off-by: Sascha Bischoff > --- > arch/arm64/kvm/vgic/vgic-init.c | 5 +- > arch/arm64/kvm/vgic/vgic-v5.c | 143 +++++++++++++++++++++++++++++ > arch/arm64/kvm/vgic/vgic.h | 1 + > include/kvm/arm_vgic.h | 6 ++ > include/linux/irqchip/arm-gic-v5.h | 2 + > 5 files changed, 156 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c > index 907057881b26a..984908a271c8d 100644 > --- a/arch/arm64/kvm/vgic/vgic-init.c > +++ b/arch/arm64/kvm/vgic/vgic-init.c > @@ -500,8 +500,11 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm) > dist->vgic_cpu_base = VGIC_ADDR_UNDEF; > } > > - if (vgic_supports_direct_irqs(kvm)) > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 && > + vgic_supports_direct_irqs(kvm)) > vgic_v4_teardown(kvm); > + else if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V5) > + vgic_v5_teardown(kvm); nit: switch/case instead? > > xa_destroy(&dist->lpi_xa); > } > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c > index fd3d6299a2baa..4e0d52b309628 100644 > --- a/arch/arm64/kvm/vgic/vgic-v5.c > +++ b/arch/arm64/kvm/vgic/vgic-v5.c > @@ -7,6 +7,7 @@ > > #include > #include > +#include > > #include "vgic.h" > #include "vgic-v5-tables.h" > @@ -162,6 +163,138 @@ int vgic_v5_probe(const struct gic_kvm_info *info) > return 0; > } > > +/* > + * This set of irq_chip functions is specific for doorbells. > + */ > +static struct irq_chip vgic_v5_db_irq_chip = { const? > + .name = "GICv5-DB", > + .irq_mask = irq_chip_mask_parent, > + .irq_unmask = irq_chip_unmask_parent, > + .irq_eoi = irq_chip_eoi_parent, > + .irq_set_affinity = irq_chip_set_affinity_parent, > + .irq_get_irqchip_state = irq_chip_get_parent_state, > + .irq_set_irqchip_state = irq_chip_set_parent_state, > + .flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE | > + IRQCHIP_MASK_ON_SUSPEND, > +}; > + > +static int vgic_v5_irq_db_domain_map(struct irq_domain *d, unsigned int virq, > + u16 vpe_id) > +{ > + int ret; > + u32 lpi; > + irq_hw_number_t hwirq; > + struct irq_chip *chip = &vgic_v5_db_irq_chip; > + struct irq_data *irqd = irq_desc_get_irq_data(irq_to_desc(virq)); > + > + /* > + * For the DB domain, we don't use the same hwirq as for LPIs. > + */ > + hwirq = vpe_id; > + > + ret = gicv5_alloc_lpi(); NAK. Allocating LPIs is the task of the underlying domain that manages LPIs, and absolutely not the vgic code. > + if (ret < 0) > + return ret; > + lpi = ret; > + > + ret = irq_domain_alloc_irqs_parent(d, virq, 1, &lpi); Why? I'd expect to see an irq_domain_alloc_irqs() for the whole VM, and be done with it. The whole allocation/freeing of LPIs is upside down. You really should not have to do this, and I'd strongly suggest you align the way the doorbell domain is constructed with the way GICv4 does it. Thanks, M. -- Without deviation from the norm, progress is not possible.