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 684A81D9A54; Sat, 10 May 2025 09:56:32 +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=1746870992; cv=none; b=kYKQY6T7AdHp+xhElbkOSbqscnCPg5zWF0qsMi1rK0k1OpTgW3inyp9AgUvomBMYGqYHOdwtp+3qxwmSLYSYE8KkpwgmSLI7SSROPFR/C8X7AJphQrgWfxL+MC4CgptygJRYbE87xswSvRihNE7Zxdf3Udl+N7AwlnrKyr93gmY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746870992; c=relaxed/simple; bh=OXVam+0Q2orOkHKRReKLiYIXpAXiFSA2E5n7tXsaBGA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Vv62oVLS2L3kibnx7g+dQ4VaR64niUDjCQDKIZOn875CmX7uq8aRxZOfmL12/QO/o9b15wnZpwnxtOWgHHW1Cidr46kfzT2pNtWaeUv9UgsS54g7jDZ5tFtXlur1u7Q/koGi2PrFCDu720Up0vszSQ8W65VKJo+JLjjw8mW6EZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FkbKUX7W; 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="FkbKUX7W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD605C4CEE2; Sat, 10 May 2025 09:56:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746870991; bh=OXVam+0Q2orOkHKRReKLiYIXpAXiFSA2E5n7tXsaBGA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FkbKUX7WqHUffy9/Z6JrTDRg1Ns4T7ZOhcGcfp2Rl3Jx5c8IT93xwWPtPgnPFdtYr 6jeWmb0WquwoJHppA3VKgLQwzczdhXkWp3VKPfJif0sbXLiM+woBOQpbxeO/u4UFxU ryoC+BLHynWrkb7lMixzhm9bMK6JJ4cORCyiIA4Z9dibbYbYfDLsA0qhK6nEKa25VH umdviRAkKRHLEeAAGXa5IgYpg5OJciAKg169fwFYfiqYyY8pHcJCuB2ed6XVP3WWgx KPYdbPCS6FZ3jD+XNBLMHkpD90e09mZn58e0dMsOtsTDqUq3UxZWoA6TtYOtb4oR9t k5NrgwpFElWJg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uDgwX-00DeFq-Jh; Sat, 10 May 2025 10:56:29 +0100 Date: Sat, 10 May 2025 10:56:29 +0100 Message-ID: <87ikm86b76.wl-maz@kernel.org> From: Marc Zyngier To: Joey Gouly Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Rutland , Fuad Tabba , Will Deacon , Catalin Marinas , Ben Horgan Subject: Re: [PATCH v4 31/43] KVM: arm64: Switch to table-driven FGU configuration In-Reply-To: <20250508155828.GB3256485@e124191.cambridge.arm.com> References: <20250506164348.346001-1-maz@kernel.org> <20250506164348.346001-32-maz@kernel.org> <20250508155828.GB3256485@e124191.cambridge.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: joey.gouly@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, mark.rutland@arm.com, tabba@google.com, will@kernel.org, catalin.marinas@arm.com, ben.horgan@arm.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, 08 May 2025 16:58:28 +0100, Joey Gouly wrote: > > On Tue, May 06, 2025 at 05:43:36PM +0100, Marc Zyngier wrote: > > Defining the FGU behaviour is extremely tedious. It relies on matching > > each set of bits from FGT registers with am architectural feature, and > > adding them to the FGU list if the corresponding feature isn't advertised > > to the guest. > > > > It is however relatively easy to dump most of that information from > > the architecture JSON description, and use that to control the FGU bits. > > > > Let's introduce a new set of tables descripbing the mapping between > > FGT bits and features. Most of the time, this is only a lookup in > > an idreg field, with a few more complex exceptions. > > > > While this is obviously many more lines in a new file, this is > > mostly generated, and is pretty easy to maintain. > > I didn't review every single value in the maps (autogenerated as you said), but > I did take a look at a few. > > __compute_fixed_bits() is pretty confusing, it's doing multiple things: > - It returns a mask of bits that didn't match (aka RES0) > - or it returns a mask of bits that may have a fixed value and fills out a > pointer with what the fixed values are. > > It has the __ prefix, so it's an implemetation-detail kinda function, not > asking you to change anything, just pointing out the most confusing part of the > patch! I know. My OCDing self couldn't deal with having two helpers differing only by the position of a single bit, hence the catch-all helper. But I'm happy to revisit this in the future to make it more palatable. It's just that I'm getting a bit fed-up with this series... :-/ > > Just one small whitespace nit below. > > Reviewed-by: Joey Gouly Thank you! > > + NEEDS_FEAT(HFGRTR_EL2_ERXPFGCDN_EL1| > > + HFGRTR_EL2_ERXPFGCTL_EL1| > > Inconsistent |. Ah, nice. Fixed. > > + NEEDS_FEAT_FLAG(HDFGRTR_EL2_OSDLR_EL1, NEVER_FGU, > > + FEAT_DoubleLock), > > This confused me at first, but it's because OSDLR_EL1 is always accessible > (with FEAT_AA64EL1), but can only be trapped with FEAT_DoubleLock. Exactly. This is the conjunction of two architectural constraints (selective output from my script): - OSDLR_EL1: # Reg cond: IsFeatureImplemented(FEAT_AA64) - HDFGRTR_EL2.OSDLR_EL1: # Field cond: IsFeatureImplemented(FEAT_DoubleLock) The first implies that this can never UNDEF, while the second indicates that the trap bit only exists under specific conditions. It's one of these cases where the architecture is playing catch-up with itself (v8.0 vs v8.6). Thanks again, M. -- Jazz isn't dead. It just smells funny.