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 X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B925AC4338F for ; Thu, 12 Aug 2021 10:09:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88D2161077 for ; Thu, 12 Aug 2021 10:09:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229956AbhHLKJ1 (ORCPT ); Thu, 12 Aug 2021 06:09:27 -0400 Received: from foss.arm.com ([217.140.110.172]:41572 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236234AbhHLKJV (ORCPT ); Thu, 12 Aug 2021 06:09:21 -0400 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 A5C3F1042; Thu, 12 Aug 2021 03:08:56 -0700 (PDT) Received: from [10.163.68.17] (unknown [10.163.68.17]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CF043F718; Thu, 12 Aug 2021 03:08:53 -0700 (PDT) Subject: Re: [RFC V2 05/10] arm64/mm: Add CONFIG_ARM64_PA_BITS_52_[LPA|LPA2] To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, suzuki.poulose@arm.com, mark.rutland@arm.com, will@kernel.org, maz@kernel.org, james.morse@arm.com, steven.price@arm.com References: <1627281445-12445-1-git-send-email-anshuman.khandual@arm.com> <1627281445-12445-6-git-send-email-anshuman.khandual@arm.com> <20210805172550.GG6719@arm.com> From: Anshuman Khandual Message-ID: <44a3f3e2-ee11-09b1-69cf-210aa2f6ddb5@arm.com> Date: Thu, 12 Aug 2021 15:39:47 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210805172550.GG6719@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/5/21 10:55 PM, Catalin Marinas wrote: > On Mon, Jul 26, 2021 at 12:07:20PM +0530, Anshuman Khandual wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index b5b13a9..1999ac6 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -934,6 +934,12 @@ config ARM64_VA_BITS >> default 48 if ARM64_VA_BITS_48 >> default 52 if ARM64_VA_BITS_52 >> >> +config ARM64_PA_BITS_52_LPA >> + bool >> + >> +config ARM64_PA_BITS_52_LPA2 >> + bool >> + >> choice >> prompt "Physical address space size" >> default ARM64_PA_BITS_48 >> @@ -948,6 +954,7 @@ config ARM64_PA_BITS_52 >> bool "52-bit (ARMv8.2)" >> depends on ARM64_64K_PAGES >> depends on ARM64_PAN || !ARM64_SW_TTBR0_PAN >> + select ARM64_PA_BITS_52_LPA if ARM64_64K_PAGES >> help >> Enable support for a 52-bit physical address space, introduced as >> part of the ARMv8.2-LPA extension. > > Do we actually need to bother with LPA, LPA2 options? We could just add These are internal configs for code organization purpose, which otherwise becomes bit entangled. Basically these configs just imply the following combinations being selected together. - ARM64_PA_BITS_52_LPA : ARM64_64K_PAGES && ARM64_PA_BITS_52 - ARM64_PA_BITS_52_LPA2 : (ARM64_4K_PAGES || ARM64_16K_PAGES) && ARM64_PA_BITS_52 There are some benefits here - ARM64_PA_BITS_52_[LPA|LPA2] helps in avoiding writing out code blocks for these above combinations in various different places, keeps it clean. - Cleanly encapsulates ARM64_PA_BITS_52 implementation into two different logical code blocks depending on the respective HW features enabling it i.e FEAT_LPA and FEAT_LPA2. This is important because there are distinct pte <----> phys encodings, ptdump handling, setting TCR_DS, FEAT_LPA2 detection, PTE sharability attribute handling which are dependent on how 52 bits PA is implemented. > an extra defined(ARM64_64K_PAGES) in places, it may be easier to follow > in a few years time when we won't remember what LPA or LPA2 was. I Are you suggesting that over the years, folks might forget about LPA/LPA2 details and might have to look back in arch/arm64/Kconfig to figure this out, which is not desirable ? But would not that be an acceptable trade off given the encapsulation it helps achieve ? > haven't got to the rest of the patches but it may just be simpler to > define the shifts separately for 52-bit based on 4K/16K/64K and ignore > the LPA/LPA2 distinction altogether (we'll still keep it for CPUID > checking though). > Sure. After you have gone through and reviewed rest of the series, if it still appears that dropping LPA/LPA2 distinction here would be simpler from a long term perspective, will be happy to change it accordingly. 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 X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08581C4338F for ; Thu, 12 Aug 2021 10:11:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8D26861038 for ; Thu, 12 Aug 2021 10:11:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8D26861038 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=Q4QHFBQd2D9JtzpoUdCRpcJVxuncSDTVvN6Su89DDl8=; b=3hLVYdJPcvfaGFX22RH4DOOAAY Z14gocRWVeJQGAzDn/D7/k1rf/DoXa2jO2WYNajoH1akDrFERUbPH6eib6zHJ+/9fzKCWpaZET9+D LGSOcKyu7KmNv3ZgRzWjf17Ji4yu1XCwLYWVIxRBsrr8U3jKbe1EZUR4LRNGfy3quYnCvdO8dsZ4D /h/gGdJjCJqpuC2i9T2jlrpCP3TB/ibESPGtMBvYik+lZnYvsXq1BT6BzS0qSKyaLEE4/J1hJ1eGI nEfuUISauF+gw8yYCI8Er1zw2SNNSx6myfCsxY070hovNHuLOr7QzvIKaRZWeL3w2KeeGxReAyl40 w0oCGALQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mE7e4-009cLV-Dk; Thu, 12 Aug 2021 10:09:04 +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 1mE7dz-009cKQ-Ps for linux-arm-kernel@lists.infradead.org; Thu, 12 Aug 2021 10:09:01 +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 A5C3F1042; Thu, 12 Aug 2021 03:08:56 -0700 (PDT) Received: from [10.163.68.17] (unknown [10.163.68.17]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CF043F718; Thu, 12 Aug 2021 03:08:53 -0700 (PDT) Subject: Re: [RFC V2 05/10] arm64/mm: Add CONFIG_ARM64_PA_BITS_52_[LPA|LPA2] To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, suzuki.poulose@arm.com, mark.rutland@arm.com, will@kernel.org, maz@kernel.org, james.morse@arm.com, steven.price@arm.com References: <1627281445-12445-1-git-send-email-anshuman.khandual@arm.com> <1627281445-12445-6-git-send-email-anshuman.khandual@arm.com> <20210805172550.GG6719@arm.com> From: Anshuman Khandual Message-ID: <44a3f3e2-ee11-09b1-69cf-210aa2f6ddb5@arm.com> Date: Thu, 12 Aug 2021 15:39:47 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210805172550.GG6719@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210812_030859_976282_B3CF7A3C X-CRM114-Status: GOOD ( 19.87 ) 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 8/5/21 10:55 PM, Catalin Marinas wrote: > On Mon, Jul 26, 2021 at 12:07:20PM +0530, Anshuman Khandual wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index b5b13a9..1999ac6 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -934,6 +934,12 @@ config ARM64_VA_BITS >> default 48 if ARM64_VA_BITS_48 >> default 52 if ARM64_VA_BITS_52 >> >> +config ARM64_PA_BITS_52_LPA >> + bool >> + >> +config ARM64_PA_BITS_52_LPA2 >> + bool >> + >> choice >> prompt "Physical address space size" >> default ARM64_PA_BITS_48 >> @@ -948,6 +954,7 @@ config ARM64_PA_BITS_52 >> bool "52-bit (ARMv8.2)" >> depends on ARM64_64K_PAGES >> depends on ARM64_PAN || !ARM64_SW_TTBR0_PAN >> + select ARM64_PA_BITS_52_LPA if ARM64_64K_PAGES >> help >> Enable support for a 52-bit physical address space, introduced as >> part of the ARMv8.2-LPA extension. > > Do we actually need to bother with LPA, LPA2 options? We could just add These are internal configs for code organization purpose, which otherwise becomes bit entangled. Basically these configs just imply the following combinations being selected together. - ARM64_PA_BITS_52_LPA : ARM64_64K_PAGES && ARM64_PA_BITS_52 - ARM64_PA_BITS_52_LPA2 : (ARM64_4K_PAGES || ARM64_16K_PAGES) && ARM64_PA_BITS_52 There are some benefits here - ARM64_PA_BITS_52_[LPA|LPA2] helps in avoiding writing out code blocks for these above combinations in various different places, keeps it clean. - Cleanly encapsulates ARM64_PA_BITS_52 implementation into two different logical code blocks depending on the respective HW features enabling it i.e FEAT_LPA and FEAT_LPA2. This is important because there are distinct pte <----> phys encodings, ptdump handling, setting TCR_DS, FEAT_LPA2 detection, PTE sharability attribute handling which are dependent on how 52 bits PA is implemented. > an extra defined(ARM64_64K_PAGES) in places, it may be easier to follow > in a few years time when we won't remember what LPA or LPA2 was. I Are you suggesting that over the years, folks might forget about LPA/LPA2 details and might have to look back in arch/arm64/Kconfig to figure this out, which is not desirable ? But would not that be an acceptable trade off given the encapsulation it helps achieve ? > haven't got to the rest of the patches but it may just be simpler to > define the shifts separately for 52-bit based on 4K/16K/64K and ignore > the LPA/LPA2 distinction altogether (we'll still keep it for CPUID > checking though). > Sure. After you have gone through and reviewed rest of the series, if it still appears that dropping LPA/LPA2 distinction here would be simpler from a long term perspective, will be happy to change it accordingly. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel