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 1348CD609A2 for ; Tue, 16 Dec 2025 15:09:42 +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=kjxDTdetu5y0eRzbhO2bgJHnnYqStBYN4cvWmznUZ58=; b=iroYzst15vrvyq362C49pmmRZX U6wRUVxEsYJq3V7t9XyaSKYj/LRdufa4Qt91z5kTs7HtJSA8sV05cKUuvE9LtThF7UJpNmiYuYdMe zH8m8ju3fiqMdYX+fUG05RG+JQYkcY/myIVETBLf+3SOkgTISb5DY6pK2fwxxBQuDrZ51L/U12KB8 1IrSC1v5NkxA2M5j8lkuTMSpkG8KjMOFgA0UEGPNOVUg21vThb0eLz/FKwA6v1VaYNhlIhgkZ//uq 1ROJe/yh5WL0BonF8442RMRnPgCjSkrGCclIvdGXp6ivr0w8OuLUgZeTqonEB/M7SIQyy0H73nF2d JnBu5RVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vVWgC-00000005Px9-0ein; Tue, 16 Dec 2025 15:09:36 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vVWgB-00000005Pwy-0REL for linux-arm-kernel@lists.infradead.org; Tue, 16 Dec 2025 15:09:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 412066001D; Tue, 16 Dec 2025 15:09:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E703AC4CEF1; Tue, 16 Dec 2025 15:09:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765897774; bh=twVbtTpVtzModEQxoqIZhvjbeQSzCf8Sp0C7H3v9DXY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ArSEYhugv29KWTEzIPGw0H7eDPN+Xuk7qiKUieC5oILT1zcsXtdRLTQ40wxcd0Yd0 +77jCq5sdMK5POkDdjMyk5BqBBDbvDpRye843PMZ0ahDvQJRbgGsqjTggngLB0QKyQ 56TM885faRwDscVFy3yNVMeGwNpQYBA2fjYt6iec3m1qdkEJz5T06PGGdddN0cdk5o 8Fwnm+nB9S7ywK5OlmElm8t0oJIbyK53eAooDu4XF2DbwB/EF1zydPR1gCcnEhZ4Ng VcSK6vMBZoJqC0hwtv5xcj14elltXOlophDEr3cMwmtNLE7WrzD6M+Bb6IuyHvkhZh lpoFR3dXSUNCw== 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 1vVWg7-0000000D618-23JM; Tue, 16 Dec 2025 15:09:31 +0000 Date: Tue, 16 Dec 2025 15:09:30 +0000 Message-ID: <868qf2o445.wl-maz@kernel.org> From: Marc Zyngier To: Sascha Bischoff Cc: "yuzenghui@huawei.com" , Timothy Hayes , Suzuki Poulose , nd , "peter.maydell@linaro.org" , "kvmarm@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "kvm@vger.kernel.org" , Joey Gouly , "lpieralisi@kernel.org" , "oliver.upton@linux.dev" Subject: Re: [PATCH 11/32] KVM: arm64: gic-v5: Trap and emulate ICH_PPI_HMRx_EL1 accesses In-Reply-To: <0f686dc9ea9e32fc37a1b11eb95b32cb958ff0a8.camel@arm.com> References: <20251212152215.675767-1-sascha.bischoff@arm.com> <20251212152215.675767-12-sascha.bischoff@arm.com> <86a4ziogjc.wl-maz@kernel.org> <0f686dc9ea9e32fc37a1b11eb95b32cb958ff0a8.camel@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, yuzenghui@huawei.com, Timothy.Hayes@arm.com, Suzuki.Poulose@arm.com, nd@arm.com, peter.maydell@linaro.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey.Gouly@arm.com, lpieralisi@kernel.org, oliver.upton@linux.dev 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 Tue, 16 Dec 2025 11:54:59 +0000, Sascha Bischoff wrote: > > On Tue, 2025-12-16 at 10:41 +0000, Marc Zyngier wrote: > > On Fri, 12 Dec 2025 15:22:39 +0000, > > Sascha Bischoff wrote: > > > > > > The ICC_PPI_HMRx_EL1 register is used to determine which PPIs use > > > Level-sensitive semantics, and which use Edge. For a GICv5 guest, > > > the > > > correct view of the virtual PPIs must be provided to the guest. > > > > s/ICH/ICC/ in $SUBJECT > > > > > > > > The GICv5 architecture doesn't provide an ICV_PPI_HMRx_EL1 or > > > > The spec disagree with you here (see 9.5.4). > > > > > ICH_PPI_HMRx_EL2 register, and therefore all guest accesses must be > > > trapped to avoid the guest directly accessing the host's > > > ICC_PPI_HMRx_EL1 state. This change hence configures the FGTs to > > > always trap and emulate guest accesses to the HMR running a > > > GICv5-based guest. > > > > The real question is what we gain by emulating this register, given > > that virtual PPIs are only guaranteed to exist if the physical > > version > > exist. If they exist, then the handling mode is defined by the > > that HW, and we can't deviate from it. > > > > Given that, I can't really see the point in trapping something that > > is > > bound to be the same thing as the host, unless this comes with > > additional restrictions, for example a mask of interrupts that are > > actually exposed to the guest. > > > > Or am I missing something? > > No, I think you're quite correct, and this doesn't add meaningful > value. > > This all stems from my misunderstanding that GICv5 vPPIs are > independent from the physical PPIs. This is not the case, however, as > the set of implemented virtual PPIs matches the physically implemented > PPIs. The handling mode for each PPI will be reflected in the > ICC/ICV_PPI_HMRx_EL1 sysregs. > > This actually has wider impacts: > > 1. It makes sense to drop this commit altogether. > > 2. When initialising the GICv5 PPIs ("KVM: arm64: gic-v5: Init > Private IRQs (PPIs) for GICv5"), we skip setting their config > (LEVEL/EDGE). > > 3. In vgic_v5_reset ("KVM: arm64: gic-v5: Reset vcpu state"), sync > the host's PPI HMR state (ICC_PPI_HMRx_EL1) to KVM's vPPI shadow > state as the virtual PPIs should match that, and we need that to > correctly handle SW-driven PPI injection. Currently, this code > actually calculates the HMR contents for trapping and emulating, > which again can be dropped altogether. > > 4. vgic_hmr can be dropped from the vgic_v5 CPUIF too. > > Does this sound reasonable to you? It does, to some extent. The one thing I have been thinking about is how to hide PPIs that are implemented by the host, but not exposed to the guest. For that, I think we need a mask of PPIs that the kernel deals with (timers, PMU, SPE one day), and use it to sanitise the HMR. For that, we still need to trap these registers. But it then begs the question: what does it mean for userspace injection of PPIs? Do we still allow it? How does userspace discover the implemented PPIs? How does userspace tells us *in advance* about that so that we can affect the above mask? At this stage, I'm tempted to say "screw that, userspace doesn't get to touch PPIs -- at least not for now". Thoughts? M. -- Without deviation from the norm, progress is not possible.