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 7A167FED9EB for ; Tue, 17 Mar 2026 16:31:37 +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=amN6gYqjsWmuZf6mpd+QHmHWe/kOSF94v0NJMskBZAs=; b=13g62hRtVQ0lS0EXplsTUNEQbN HLF8U5vDpZZLbntLKBaI7r956+tNXaSkHH6UrmwO9g3XNL4xmvbonoQrUPgfTmjjZoc1RceZqwuMv I95oCdGrxSuIUKx+vIpxY9uWbnmiT28m+NnEijKpOvyAkBaZr+DxKlRPekdJVGmLhPO7EzVJoCggG M2maSmyThpDVOJszWdoioHwQf2Xd6kqmqjtGrj5xyF+hXwxbcNPEb0sBp+0p4ZVRwnxt/8InvGlTh iYbtQ91bb7uxLQw06HM80TA4QoRYwDv9qCnWHBINItTm7gregETkQ5e9cUXj0uowcAqvubPYKdkth 24uA2vNQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2XKM-00000006p9C-0dyG; Tue, 17 Mar 2026 16:31:30 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2XKJ-00000006p8o-1dqH for linux-arm-kernel@lists.infradead.org; Tue, 17 Mar 2026 16:31:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id A713C42DC4; Tue, 17 Mar 2026 16:31:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A10EC4CEF7; Tue, 17 Mar 2026 16:31:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773765086; bh=Ch1L6z1Gn5uPEJltO7XnLKXIzBRWjl1jEv6JHJnsz1k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FfaQCmLq5oKhKGC/NNf7Tqv7RM7TsVq+6STfX2BsFDXJpF0w7u1WWWPEByCEL4zpa rk9tHskJIjawU0Mf1O3qw/wh6t5X1B0A1RqbTf1wrSssIP4c2MDiwpBf85g/vfG2aB p6pHMc4bmwA6hV/ovOnTaqTV0/rcuCDMf9spF/oSO6H6xkcDUp2GAi8b5cPn8h7dfd J/qaX1eYLy4EcJX+bPhZsCJdphexECp/s11ffkjidy9ncgV3++okLYegmfiOnboLTh wU8hiPJR4WkNa8GBAwKjwQfdyBd5t48rjtw6GRhpM+EKtCWRvbQoEzCqGOULzxyyfJ Iy/DXgQfy7v2g== 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 1w2XKG-00000002vfd-0des; Tue, 17 Mar 2026 16:31:24 +0000 Date: Tue, 17 Mar 2026 16:31:23 +0000 Message-ID: <86ikau5sf8.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 v6 19/39] KVM: arm64: gic-v5: Implement PPI interrupt injection In-Reply-To: <20260317113949.2548118-20-sascha.bischoff@arm.com> References: <20260317113949.2548118-1-sascha.bischoff@arm.com> <20260317113949.2548118-20-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-20260317_093128_139233_959677F1 X-CRM114-Status: GOOD ( 38.23 ) 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 Tue, 17 Mar 2026 11:44:55 +0000, Sascha Bischoff wrote: > > This change introduces interrupt injection for PPIs for GICv5-based > guests. > > The lifecycle of PPIs is largely managed by the hardware for a GICv5 > system. The hypervisor injects pending state into the guest by using > the ICH_PPI_PENDRx_EL2 registers. These are used by the hardware to > pick a Highest Priority Pending Interrupt (HPPI) for the guest based > on the enable state of each individual interrupt. The enable state and > priority for each interrupt are provided by the guest itself (through > writes to the PPI registers). > > When Direct Virtual Interrupt (DVI) is set for a particular PPI, the > hypervisor is even able to skip the injection of the pending state > altogether - it all happens in hardware. > > The result of the above is that no AP lists are required for GICv5, > unlike for older GICs. Instead, for PPIs the ICH_PPI_* registers > fulfil the same purpose for all 128 PPIs. Hence, as long as the > ICH_PPI_* registers are populated prior to guest entry, and merged > back into the KVM shadow state on exit, the PPI state is preserved, > and interrupts can be injected. > > When injecting the state of a PPI the state is merged into the > PPI-specific vgic_irq structure. The PPIs are made pending via the > ICH_PPI_PENDRx_EL2 registers, the value of which is generated from the > vgic_irq structures for each PPI exposed on guest entry. The > queue_irq_unlock() irq_op is required to kick the vCPU to ensure that > it seems the new state. The result is that no AP lists are used for > private interrupts on GICv5. > > Prior to entering the guest, vgic_v5_flush_ppi_state() is called from > kvm_vgic_flush_hwstate(). This generates the pending state to inject > into the guest, and snapshots it (twice - an entry and an exit copy) > in order to track any changes. These changes can come from a guest > consuming an interrupt or from a guest making an Edge-triggered > interrupt pending. > > When returning from running a guest, the guest's PPI state is merged > back into KVM's vgic_irq state in vgic_v5_merge_ppi_state() from > kvm_vgic_sync_hwstate(). The Enable and Active state is synced back for > all PPIs, and the pending state is synced back for Edge PPIs (Level is > driven directly by the devices generating said levels). The incoming > pending state from the guest is merged with KVM's shadow state to > avoid losing any incoming interrupts. > > Signed-off-by: Sascha Bischoff > Reviewed-by: Jonathan Cameron > --- > arch/arm64/kvm/vgic/vgic-v5.c | 143 ++++++++++++++++++++++++++++++++++ > arch/arm64/kvm/vgic/vgic.c | 41 ++++++++-- > arch/arm64/kvm/vgic/vgic.h | 25 +++--- > 3 files changed, 194 insertions(+), 15 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c > index 07f416fbc4bc8..e080fce61dc35 100644 > --- a/arch/arm64/kvm/vgic/vgic-v5.c > +++ b/arch/arm64/kvm/vgic/vgic-v5.c > @@ -122,6 +122,149 @@ int vgic_v5_finalize_ppi_state(struct kvm *kvm) > return 0; > } > > +/* > + * For GICv5, the PPIs are mostly directly managed by the hardware. We (the > + * hypervisor) handle the pending, active, enable state save/restore, but don't > + * need the PPIs to be queued on a per-VCPU AP list. Therefore, sanity check the > + * state, unlock, and return. > + */ > +static bool vgic_v5_ppi_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq, > + unsigned long flags) > + __releases(&irq->irq_lock) > +{ > + struct kvm_vcpu *vcpu; > + > + lockdep_assert_held(&irq->irq_lock); > + > + if (WARN_ON_ONCE(!__irq_is_ppi(KVM_DEV_TYPE_ARM_VGIC_V5, irq->intid))) > + goto out_unlock_fail; > + > + vcpu = irq->target_vcpu; > + if (WARN_ON_ONCE(!vcpu)) > + goto out_unlock_fail; > + > + raw_spin_unlock_irqrestore(&irq->irq_lock, flags); > + > + /* Directly kick the target VCPU to make sure it sees the IRQ */ > + kvm_make_request(KVM_REQ_IRQ_PENDING, vcpu); > + kvm_vcpu_kick(vcpu); > + > + return true; > + > +out_unlock_fail: > + raw_spin_unlock_irqrestore(&irq->irq_lock, flags); > + > + return false; > +} > + > +static struct irq_ops vgic_v5_ppi_irq_ops = { > + .queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock, > +}; > + > +void vgic_v5_set_ppi_ops(struct vgic_irq *irq) > +{ > + if (WARN_ON(!irq)) > + return; > + > + guard(raw_spinlock_irqsave)(&irq->irq_lock); > + > + if (!WARN_ON(irq->ops)) > + irq->ops = &vgic_v5_ppi_irq_ops; > +} Why isn't this a call to kvm_vgic_set_irq_ops()? It feels very odd to have two ways to do the same thing. Thanks, M. -- Without deviation from the norm, progress is not possible.