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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BE5AC433EF for ; Thu, 12 May 2022 17:41:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91B8E6B0074; Thu, 12 May 2022 13:41:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CC756B0075; Thu, 12 May 2022 13:41:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 794BF6B0078; Thu, 12 May 2022 13:41:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6AD566B0074 for ; Thu, 12 May 2022 13:41:33 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3C8A832171 for ; Thu, 12 May 2022 17:41:33 +0000 (UTC) X-FDA: 79457808066.29.8B8E9EA Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf12.hostedemail.com (Postfix) with ESMTP id 04331400A0 for ; Thu, 12 May 2022 17:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652377290; x=1683913290; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bQdeZOucoJbqYuT7kPG2s5fmlDJK3T7fnukLOSrfHWs=; b=kj6S8sLPuE9UzlhdezZ6gINAiv/bQR6JLDLZwdboAIUgxL8QBTWGgk/7 RIGkmi3qUi+bjaRSWEsBZsXyWfB6aTlmzS3sAbUqVyC6LXmFx5RnG4k60 3oXc32HDGvzn7TPDEy+a1Qi6BYUF0sOExbMZje4t7FviJFQQXGry8SIxI XQVtPKuevHFHioisE+W6eh7l85qS1qu3TLD+XeiANiLjz5dOREYZ2XTnO gugfTJ29FsjIAHbDmxtIrGOqwyLWBWruInLHJnZ35RfC+jXEqw++mESmq 76PMtkX2m9wdfwxqORSBcMj3XdwySfjEFaOKEczZnbWAsxXq/Yi6bD032 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10345"; a="249986322" X-IronPort-AV: E=Sophos;i="5.91,220,1647327600"; d="scan'208";a="249986322" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2022 10:22:49 -0700 X-IronPort-AV: E=Sophos;i="5.91,220,1647327600"; d="scan'208";a="572617956" Received: from wdwickar-mobl1.amr.corp.intel.com (HELO [10.252.130.245]) ([10.252.130.245]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2022 10:22:48 -0700 Message-ID: <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> Date: Thu, 12 May 2022 10:22:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [RFCv2 00/10] Linear Address Masking enabling Content-Language: en-US To: Peter Zijlstra , "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , x86@kernel.org, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> From: Dave Hansen In-Reply-To: <20220511064943.GR76023@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 04331400A0 X-Stat-Signature: a537jxazdco1a9ppixyabiyjbzeejtrk X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kj6S8sLP; spf=none (imf12.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1652377266-928394 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/10/22 23:49, Peter Zijlstra wrote: >> The feature competes for bits with 5-level paging: LAM_U48 makes it >> impossible to map anything about 47-bits. The patchset made these >> capability mutually exclusive: whatever used first wins. LAM_U57 can be >> combined with mappings above 47-bits. > So aren't we creating a problem with LAM_U48 where programs relying on > it are of limited sustainability? I think allowing apps to say, "It's LAM_U48 or bust!" is a mistake. It's OK for a debugging build that runs on one kind of hardware. But, if we want LAM-using binaries to be portable, we have to do something different. One of the stated reasons for adding LAM hardware is that folks want to use sanitizers outside of debugging environments. To me, that means that LAM is something that the same binary might run with or without. It's totally fine with me if the kernel only initially supports LAM_U57. But, I'd ideally like to make sure that the ABI can support LAM_U57, LAM_U48, AMD's UAI (in whatever form it settles), or other masks.