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 F1A74C4332F for ; Mon, 14 Nov 2022 12:11:29 +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=4PF4O2jlZYO++rjWSJLyw+rllEp9DMRzJtbeLEQZw7s=; b=xt4srSGCO8i/YL pa/MhTJETRx+AIGkAZnwFcPcQS4r1t/oOvbYl2E7+HG1d0giFyNTGpaxyeioDtfJnZbG4SoSpTjO5 pQ6hXyMqC216NkptyGwmWJgCd8jYnGPvvSZQO5aUTBd7qNjQG2LkXkQVJj5VyvAg3amgmmcXvjZkR bQH6c3q03Yx5l2Om4QETC6mmpFlMbwJOoAnfHZuBu4Lc7kcwbQ0TY5pUZJm/KK28bQKRVmYZtT6di k5F9/PmI/vCyj2hVNnwb1m7tI26LQWZgOm4GjI8Ewo4+9sBPGXVqr2SVr1+hE7nmv5L/GXW50nwbp CxZARrRLvin5lkxrTVPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouYIP-000i1G-5d; Mon, 14 Nov 2022 12:10:37 +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 1ouYIL-000hyH-Gy for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 12:10:35 +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 9A3F323A; Mon, 14 Nov 2022 04:10:36 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.70.96]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E3713F73D; Mon, 14 Nov 2022 04:10:29 -0800 (PST) Date: Mon, 14 Nov 2022 12:10:23 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64: booting: Require placement within 48-bit addressable memory Message-ID: References: <20221114115810.1369005-1-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221114115810.1369005-1-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_041033_635413_349DB618 X-CRM114-Status: GOOD ( 24.46 ) 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 Mon, Nov 14, 2022 at 12:58:10PM +0100, Ard Biesheuvel wrote: > Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical > placement of the kernel image outside of the 48-bit addressable region, > but given that the loader has no way of knowing whether or not the image > in question supports LVA/LPA, it currently has no choice but to place it > below the 48-bit mark. > > Once we add support for LPA2, which allows 52-bit physical and virtual > addressing when using 4k or 16k pages, but in way that relies on > increasing the number of paging levels, there will be more variety in > the configurations that may or may not support this. > > So repaint bit #3 in the Image header as 'must be placed within 48-bit > addressable memory', as this is the current de facto meaning, and add > bits that we may set later to allow placement outside of that. Could we just clean up the definition of bit 3 for now, then add the other bits when we actually set them? > > Signed-off-by: Ard Biesheuvel > --- > Documentation/arm64/booting.rst | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 8c324ad638de2b27..9919e1a107add655 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -114,16 +114,21 @@ Header notes: > * 1 - 4K > * 2 - 16K > * 3 - 64K > - Bit 3 Kernel physical placement > + Bit 3-4 Kernel physical placement > > 0 > 2MB aligned base should be as close as possible > to the base of DRAM, since memory below it is not > accessible via the linear mapping > 1 > + 2MB aligned base such that base plus image_size is > + entirely within the 48-bit addressable range This seems to assume text_offset is zero (which is the case today, but this is the first part of booting.txt that assumes that); as a matter of policy are we sure that we'll never use a non-zero offset again? If so, we probably want to mention that in the "header notes" section, or come up with some wording to include it here. Otherwise, this looks good; I'm certainly in favour of explicitly mentioning the 48-bit restriction. Thanks, Mark. > + 2 > + Reserved > + 3 > 2MB aligned base may be anywhere in physical > memory > - Bits 4-63 Reserved. > + Bits 5-63 Reserved. > ============= =============================================================== > > - When image_size is zero, a bootloader should attempt to keep as much > -- > 2.35.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel