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 49E06C3DA42 for ; Sat, 13 Jul 2024 07:57:21 +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=/RI51fsqUm83WfA5962Ys07xVhWqbbJiOzvRHiHdHVg=; b=OomBGyuECvou+vi6DLtzs73Dya C1QsUth404fQVnP5LyIQNkHT6uRy5KpKNWF7S0wkjlNybadEorTm/UfX1uD9GnrsXnFXS2k7UNfhF hBA2Y0kj8ua+opf3gdK2963ErKJL5N3/4GF2xnQ6R16JnT4LtqTSYmjXHb2Sp64S+FSwm9IambkQ1 dzMU3cEA/4Jr7WOM6UBmLPAnWRxf5g/pG4YVsmRC+HUj/tk66cRmyg6bTpQztzEihAHGkNFxgm2Mo As2xPLaIgmqV3vgZB794OTdteXqwCf7x1+saQ60WUOsVTTN2G4Diu26WcqAwmXuyChPhlhP3QOPYd c7afHe7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sSXcy-00000002943-2Wdi; Sat, 13 Jul 2024 07:57:08 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sSXcf-0000000291a-2sai for linux-arm-kernel@lists.infradead.org; Sat, 13 Jul 2024 07:56:51 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 67FC3CE010F; Sat, 13 Jul 2024 07:56:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC5F4C32781; Sat, 13 Jul 2024 07:56:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720857405; bh=A/PyRr7IsD9YlgrQVbFDHE8HJAaoidtlMiLz27gfT3w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TE8BzzH98yOf23UKI3yK1WsDIDrepjSUtLADIviQpm0eZkaddnr26ZEgHtyQsX/Cu 9SRCDkeLtCs0Vp8kKnkI+bYhL07mdbI9jHIl65AwoVomnO95Bm5wKECZbhTgiG05uM L5ZqSGYiXGY/CWzf4BfrIFUvOQi8fKPCU10nZm6WTY4H+If7QW5M9Nl9T81dnbmlFi WQnaWJ/gq+XWKL9H6+84hVjS/pxGBRatOzvgr3x/gGl4dvodcN1jtVVo7ZuKIS/4gk QaB2Bp2AZMET0LC/hM85idH28uSHFGYS2zQDM+e7DjSmUxmM6rOkA1NTtepbuOXAFG yzn/DIX/UCieg== Received: from [213.208.208.122] (helo=wait-a-minute.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 1sSXcZ-00C3go-AU; Sat, 13 Jul 2024 08:56:43 +0100 Date: Sat, 13 Jul 2024 08:56:42 +0100 Message-ID: <871q3xpvwl.wl-maz@kernel.org> From: Marc Zyngier To: Anshuman Khandual Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Joey Gouly Subject: Re: [PATCH 02/12] arm64: Add PAR_EL1 field description In-Reply-To: References: <20240625133508.259829-1-maz@kernel.org> <20240625133508.259829-3-maz@kernel.org> 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/28.2 (x86_64-pc-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: 213.208.208.122 X-SA-Exim-Rcpt-To: anshuman.khandual@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, joey.gouly@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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240713_005650_103944_75D1BC41 X-CRM114-Status: GOOD ( 22.81 ) 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 Fri, 12 Jul 2024 08:06:31 +0100, Anshuman Khandual wrote: > > > > On 6/25/24 19:05, Marc Zyngier wrote: > > As KVM is about to grow a full emulation for the AT instructions, > > add the layout of the PAR_EL1 register in its non-D128 configuration. > > Right, there are two variants for PAR_EL1 i.e D128 and non-D128. Probably it makes > sense to define all these PAR_EL1 fields in arch/arm64/include/asm/sysreg.h, until > arch/arm64/tools/sysreg evolves to accommodate different bit field layouts for the > same register. This is really sorely needed, because we can't describe any of the registers that changes layout depending on another control bit. Take for example any of the EL2 registers affected by HCR_EL2.E2H. However, I have no interest in defining *any* D128 format. I take it that whoever will eventually add D128 support to the kernel (and KVM) will take care of that. > > > > > Note that the constants are a bit ugly, as the register has two > > layouts, based on the state of the F bit. > > Just wondering if it would be better to append 'VALID/INVALID' suffix > for the fields to differentiate between when F = 0 and when F = 1 ? > > s/SYS_PAR_EL1_FST/SYS_PAR_INVALID_FST_EL1 > s/SYS_PAR_EL1_SH/SYS_PAR_VALID_SH_EL1 > > Or something similar. I find it pretty horrible. If anything, because "VALID/INVALID" doesn't say anything of *what* is invalid. Also, there is no "VALID" definition in the register, and an aborted translation does not make the register invalid, quite the opposite -- it is full of crucial information. Which is why I used the F0/F1 prefixes, making it clear (at least in my view) that the description is tied to a particular value of the PAR_EL1.F bit. Finally, most of the bit layouts are unambiguous: a field of any given name only exists in a given layout of the register. This means we can safely have names that match the ARM ARM description without any visual pollution. The only ambiguities are with generic names such as RES0 and IMPDEF. Given that we almost never use these bits for anything, I don't think the use of a F-specific prefix is a problem. But yeah, naming is hard. M. -- Without deviation from the norm, progress is not possible.