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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 B1F1EC5DF62 for ; Wed, 6 Nov 2019 11:23:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 75BDA206A3 for ; Wed, 6 Nov 2019 11:23:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731376AbfKFLXP (ORCPT ); Wed, 6 Nov 2019 06:23:15 -0500 Received: from foss.arm.com ([217.140.110.172]:38158 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726101AbfKFLXP (ORCPT ); Wed, 6 Nov 2019 06:23:15 -0500 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 78A097A7; Wed, 6 Nov 2019 03:23:14 -0800 (PST) Received: from arrakis.emea.arm.com (unknown [10.1.197.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2525F3F6C4; Wed, 6 Nov 2019 03:23:13 -0800 (PST) Date: Wed, 6 Nov 2019 11:23:11 +0000 From: Catalin Marinas To: Bhupesh Sharma Cc: linux-arm-kernel@lists.infradead.org, bhupesh.linux@gmail.com, James Morse , Mark Rutland , Will Deacon , Steve Capper , Ard Biesheuvel , linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH] arm64: mm: Remove MAX_USER_VA_BITS definition Message-ID: <20191106112310.GG21133@arrakis.emea.arm.com> References: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 05, 2019 at 03:26:46AM +0530, Bhupesh Sharma wrote: > commit 9b31cf493ffa ("arm64: mm: Introduce MAX_USER_VA_BITS definition") > introduced the MAX_USER_VA_BITS definition, which was used to support > the arm64 mm use-cases where the user-space could use 52-bit virtual > addresses whereas the kernel-space would still could a maximum of 48-bit > virtual addressing. > > But, now with commit b6d00d47e81a ("arm64: mm: Introduce 52-bit Kernel > VAs"), we removed the 52-bit user/48-bit kernel kconfig option and hence > there is no longer any scenario where user VA != kernel VA size > (even with CONFIG_ARM64_FORCE_52BIT enabled, the same is true). > > Hence we can do away with the MAX_USER_VA_BITS macro as it is equal to > VA_BITS (maximum VA space size) in all possible use-cases. Note that > even though the 'vabits_actual' value would be 48 for arm64 hardware > which don't support LVA-8.2 extension (even when CONFIG_ARM64_VA_BITS_52 > is enabled), VA_BITS would still be set to a value 52. Hence this change > would be safe in all possible VA address space combinations. > > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: linux-kernel@vger.kernel.org > Cc: kexec@lists.infradead.org > Signed-off-by: Bhupesh Sharma Queued for 5.5. Thanks. -- Catalin 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=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 8215CC5DF62 for ; Wed, 6 Nov 2019 11:23:24 +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 4E8682077C for ; Wed, 6 Nov 2019 11:23:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ETWN+szt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E8682077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=qC/qY4zkK6m/bSrLOquHOyPCTpjaR4j1QkkDcTvkwJc=; b=ETWN+szt/Xs9fL esRT6AsoKiCUP5rXOwZYSwab0HqBAxyxC8EM4tI1+WHF3C8JXdi9WdXAYT5cBTeoox6SCVdzigZqW iuSuVcjOQue8XvEBU9CyPZUJ/e2kHz29M8TF/8L90bRT0atlt/ARBsscK4TVi/nk4OpW22rAxmqqm vVpg747jUqAdUWHhdkMxd46CgjDuPJMrhxxVp902xke/dEdFmDiZALcmhhHncKCjysq5D+5hVjX3H zCy2tvVivGmR5PofsDEu4TpVZqx7gWMlUpPu0qyk6iH9bC+zb4RMxu9hz4CTc8cjB12MZs8NNJYNR fW+/dTN2vFmQYLAbZv0w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSJPE-0001KD-AQ; Wed, 06 Nov 2019 11:23:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSJPA-0001Ia-IY; Wed, 06 Nov 2019 11:23:18 +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 78A097A7; Wed, 6 Nov 2019 03:23:14 -0800 (PST) Received: from arrakis.emea.arm.com (unknown [10.1.197.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2525F3F6C4; Wed, 6 Nov 2019 03:23:13 -0800 (PST) Date: Wed, 6 Nov 2019 11:23:11 +0000 From: Catalin Marinas To: Bhupesh Sharma Subject: Re: [PATCH] arm64: mm: Remove MAX_USER_VA_BITS definition Message-ID: <20191106112310.GG21133@arrakis.emea.arm.com> References: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191106_032316_655168_98D4D45E X-CRM114-Status: GOOD ( 11.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Steve Capper , Ard Biesheuvel , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, James Morse , bhupesh.linux@gmail.com, Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 05, 2019 at 03:26:46AM +0530, Bhupesh Sharma wrote: > commit 9b31cf493ffa ("arm64: mm: Introduce MAX_USER_VA_BITS definition") > introduced the MAX_USER_VA_BITS definition, which was used to support > the arm64 mm use-cases where the user-space could use 52-bit virtual > addresses whereas the kernel-space would still could a maximum of 48-bit > virtual addressing. > > But, now with commit b6d00d47e81a ("arm64: mm: Introduce 52-bit Kernel > VAs"), we removed the 52-bit user/48-bit kernel kconfig option and hence > there is no longer any scenario where user VA != kernel VA size > (even with CONFIG_ARM64_FORCE_52BIT enabled, the same is true). > > Hence we can do away with the MAX_USER_VA_BITS macro as it is equal to > VA_BITS (maximum VA space size) in all possible use-cases. Note that > even though the 'vabits_actual' value would be 48 for arm64 hardware > which don't support LVA-8.2 extension (even when CONFIG_ARM64_VA_BITS_52 > is enabled), VA_BITS would still be set to a value 52. Hence this change > would be safe in all possible VA address space combinations. > > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: linux-kernel@vger.kernel.org > Cc: kexec@lists.infradead.org > Signed-off-by: Bhupesh Sharma Queued for 5.5. Thanks. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Wed, 6 Nov 2019 11:23:11 +0000 From: Catalin Marinas Subject: Re: [PATCH] arm64: mm: Remove MAX_USER_VA_BITS definition Message-ID: <20191106112310.GG21133@arrakis.emea.arm.com> References: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1572904606-27961-1-git-send-email-bhsharma@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Bhupesh Sharma Cc: Mark Rutland , Steve Capper , Ard Biesheuvel , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, James Morse , bhupesh.linux@gmail.com, Will Deacon , linux-arm-kernel@lists.infradead.org On Tue, Nov 05, 2019 at 03:26:46AM +0530, Bhupesh Sharma wrote: > commit 9b31cf493ffa ("arm64: mm: Introduce MAX_USER_VA_BITS definition") > introduced the MAX_USER_VA_BITS definition, which was used to support > the arm64 mm use-cases where the user-space could use 52-bit virtual > addresses whereas the kernel-space would still could a maximum of 48-bit > virtual addressing. > > But, now with commit b6d00d47e81a ("arm64: mm: Introduce 52-bit Kernel > VAs"), we removed the 52-bit user/48-bit kernel kconfig option and hence > there is no longer any scenario where user VA != kernel VA size > (even with CONFIG_ARM64_FORCE_52BIT enabled, the same is true). > > Hence we can do away with the MAX_USER_VA_BITS macro as it is equal to > VA_BITS (maximum VA space size) in all possible use-cases. Note that > even though the 'vabits_actual' value would be 48 for arm64 hardware > which don't support LVA-8.2 extension (even when CONFIG_ARM64_VA_BITS_52 > is enabled), VA_BITS would still be set to a value 52. Hence this change > would be safe in all possible VA address space combinations. > > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: linux-kernel@vger.kernel.org > Cc: kexec@lists.infradead.org > Signed-off-by: Bhupesh Sharma Queued for 5.5. Thanks. -- Catalin _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec