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 AF741C433F5 for ; Fri, 28 Jan 2022 10:06:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bp7DXtuN37c6zXYtyR4wiPxr4kP81Y6uvCyLRNaht2M=; b=nUqqLlzMwSl3XN r56eG94wBf0tWFnaJrO4GMamKBY7g4x2YN97tiDw5DoH7kvaeOKWMG/yIoci79gNu9P629H/gwXLI VyYKFDNTz58h5LbgQSTXL0g4gIWUzr4v8zoKjzaIxVCJ+kVQ3eklH4GFL7lyh2gRUEzS6HIsU44mg 0AtQXlr3X3VWwsLE9Rr90HsPLzNytGUEhGLhVFkMzMMD3vGinHyOYz2jiKQLV+Bq6WiCdtWLvZMnM LViEvDR3HFFsFmvWi59SpO2ra80XeHMgjA/3yWQSUZi6AfeYvjbmpd71TK/UKEsjx89ANZDjkQ1iw GC4hGB/DF1qNKqyUyxZg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nDO7z-001NB3-K0; Fri, 28 Jan 2022 10:05:12 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nDO73-001My0-LP for linux-arm-kernel@lists.infradead.org; Fri, 28 Jan 2022 10:04:15 +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 A0A3B113E; Fri, 28 Jan 2022 02:04:11 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.13.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4194E3F766; Fri, 28 Jan 2022 02:04:10 -0800 (PST) Date: Fri, 28 Jan 2022 10:03:57 +0000 From: Mark Rutland To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com, jaxson.han@arm.com, robin.murphy@arm.com, vladimir.murzin@arm.com, wei.chen@arm.com Subject: Re: [bootwrapper PATCH v3 01/15] aarch64: correct ZCR_EL3.LEN initialization Message-ID: References: <20220125150057.3936090-1-mark.rutland@arm.com> <20220125150057.3936090-2-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220128_020413_797487_D335DBA0 X-CRM114-Status: GOOD ( 27.32 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 27, 2022 at 06:55:00PM +0000, Mark Brown wrote: > On Thu, Jan 27, 2022 at 04:08:50PM +0000, Mark Rutland wrote: > > On Tue, Jan 25, 2022 at 05:44:47PM +0000, Mark Brown wrote: > > > On Tue, Jan 25, 2022 at 04:33:39PM +0000, Mark Rutland wrote: > > > > On Tue, Jan 25, 2022 at 03:59:38PM +0000, Mark Brown wrote: > > > > > a) Use __ definition, as here. > > > > > b) Use __MASK, and add comments at each usage as to why we use > > > > a mask as a value, to explain why that isn't a bug. > > > > > c) Have both __MASK and some value definition, and use some > > > > insertion helper to insert the value. > > > > > ... and I went with (a) because it was the simplest. > > > > > Is there a problem with this? > > > > My concern is continuity of the enumeration algorithm between the > > > various implementations we have, it's something we're not currently > > > great with and this creates a separation between the kernel and the boot > > > wrapper implementations. There's no change in what's actually being > > > done but it creates some additional effort to figure out why we're > > > setting a maximum here and not trying to set all the bits as we do in > > > the kernel. > > > TBH, I'd argue if we're setting those bits in the kernel it's probably a bug, > > because we don't know *exactly* what effect they'll have when allocated in the > > future. > > My comments there are related purely to the renaming of the constant, > not to the narrowing of the bitmask which is less of an issue. Ok. > Basically avoiding the question "why is that a maximum and not a mask" > and if there's limits on the valid values that are more restrictive than > the representable values. > > The ideal thing for the boot wrapper would be option (c) with either a > configuration option to set the maximum to something lower than all > bits, unless someone was unduly enthusiastic and wanted to have an all > CPUs enumeration algorithm, but both are probably more trouble than it's > worth. FWIW, if it's useful for testing to be able to configure the ZCR_EL3.LEN to some smaller value, I'd be happy to move to (c) and get that plumbed into the build system. For now, I plan to take the series with this as-is, since having ZCR_EL3_LEN_MAX is consistent with other field values we only insert, e.g. MDCR_EL3_NSPB_NS_NOTRAP. I'm happy to rejig that in future. Thanks, Mark _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel