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 00061C3DA64 for ; Tue, 6 Aug 2024 13:29:44 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From: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=DIlbjxItpCxlmjnL100gc4Rl2esmPY8hlWOqtcXhAow=; b=CZSW+jX/+nCFSKp88TT+Sg+PZa a3hNXgGJYs+LfB78lHd2O/Ltjzvqxwpv1pIOtoB9ssyDXGwRd0IWMWxFmrWKvzpRy2Gt/NITFa/ac W0paHFimBv3nUtGOMAMgwbHXl1NbhKw90kAyQ+y1975aBtYFTTs1kkERyftdnPvYcKg4JnBPZl8CY FFh4T2b6OMYMiP2cFkTNGY7g7httvxqYFV9AmpiI6lJk2HlK4HRvxTAqQYbTWwPPdLvlwtCoJx/GQ rf+jF1VOh90sXlHvq3PH2QhGV8YIWJHnfq/0Iapb5wK/dYv8eDW36Ldr8RGA11el6LpzLyA5i7ql4 UqWYUCEw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbKFp-00000001mQC-17Yk; Tue, 06 Aug 2024 13:29:33 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbKEq-00000001lxc-24oQ for linux-arm-kernel@lists.infradead.org; Tue, 06 Aug 2024 13:28:33 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F04E4FEC; Tue, 6 Aug 2024 06:28:55 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 272243F766; Tue, 6 Aug 2024 06:28:29 -0700 (PDT) Date: Tue, 6 Aug 2024 14:28:23 +0100 From: Mark Rutland To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Mark Brown , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/1] arm64/tools/sysreg: Add Sysreg128/SysregFields128 Message-ID: References: <20240801054436.612024-1-anshuman.khandual@arm.com> <88e4f6eb-9ce5-4f52-9f4c-4511fe054b94@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88e4f6eb-9ce5-4f52-9f4c-4511fe054b94@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240806_062832_662293_C9F24463 X-CRM114-Status: GOOD ( 32.33 ) 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, Aug 05, 2024 at 08:30:48AM +0530, Anshuman Khandual wrote: > On 8/3/24 16:37, Mark Rutland wrote: > > On Thu, Aug 01, 2024 at 11:14:35AM +0530, Anshuman Khandual wrote: > >> FEAT_SYSREG128 enables 128 bit wide system registers which also need to be > >> defined in (arch/arm64/toos/sysreg) for auto mask generation. This adds two > >> new field types i.e Sysreg128 and SysregFields128 for that same purpose. It > >> utilizes recently added macro GENMASK_U128() while also adding some helpers > >> such as define_field_128() and parse_bitdef_128(). > >> > >> This patch applies after the following series which adds GENMASK_U128() > >> > >> https://lore.kernel.org/all/20240725054808.286708-1-anshuman.khandual@arm.com/ > > > > Is that patch merged or not? It wouod make a lot more sense to send them > > together as one series. > > The latest series [1] here has been reviewed and merged in bitmap-for-next > tree for testing purpose. Also there has been an additional patch [2] just > to keep the GENMASK_U128() helpers inside !__ASSEMBLY__ guard. > > [1] https://lore.kernel.org/all/20240801071646.682731-1-anshuman.khandual@arm.com/ > [2] https://lore.kernel.org/all/20240803133753.1598137-1-yury.norov@gmail.com/ > > GENMASK_U128() series could have been part of this series, although 128 bit > mask creation seems generic enough to stand on its own. > > >> A. Example for SysregFields128 > >> > >> ------------------------------ > >> SysregFields128 TTBRx_D128_EL1 > >> Res0 127:88 > >> Field 87:80 BADDR_HIGH > >> Res0 79:64 > >> Field 63:48 ASID > >> Field 47:5 BADDR_LOW > >> Res0 4:3 > >> Field 2:1 SKL > >> Field 0 CnP > >> EndSysregFields128 > >> ------------------------------ > > > > Ok, so we get the definitions, but do we have all the other helpers we'd > > need to make that useable, i.e. > > The first objective was to get the definitions right, so that they could > be stored in the new gcc __unit128 data type. I can understand that being the first thing you do while prototyping, but upstream we don't even know that we *want* to use __unit128, becuase whether that is desireable depends on how we can *consume* the values. > > * read_sysreg() and write_sysreg() variants that can use MRRS/MSRR > > > > * Macros for assembly to use these? > > > > * Other bitfield manipulation helpers that can operate on U128, e.g. > > FIELD_GET() and FIELD_PREP() ? > > These are still work in progress, but will share when available. > > > Without end-to-end usage this is a bit academic. If the U128 definitions > > are oainful to use from asm we might want separate hi64/lo64 > > definitions. > > Right, U128 definitions are difficult to use in asm code because they way > gcc compiler deals with 128 bit data types. I meant that this is likely to be painful even for plain where the compiler is not involved, because the *assembler* cannot handle bits 127:64, e.g. | [mark@gravadlaks:~]% cat test.S | .if ((1 << 32) >> 32) != 1 | .error "Oh no! absolute expressions are evaluated as 32-bits or less" | .endif | | .if ((((1 << 32) << 32) >> 32) >> 32) != 1 | .error "Oh no! absolute expressions are evaluated as 64-bits or less" | .endif | [mark@gravadlaks:~]% as test.S -o test.o | test.S: Assembler messages: | test.S:6: Error: Oh no! absolute expressions are evaluated as 64-bits or less ... and so either we have to handle the hi64/lo64 halves explicitly when generating definitions, or we need the assembler to gain support for 128-bit absolute expressions. ... and if we go for the former, we don't need U128 at all; hence why it would have made more sense to do this in one go. > Should the separate hi64/lo64 definitions be generic or platform > specific without adding them to kernel bitops ? I don't understand that question here. I was describing the problem of the bit definitions, not operations operating upon those definitions. Mark.