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=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 04530C2B9F4 for ; Fri, 25 Jun 2021 22:35:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8769861606 for ; Fri, 25 Jun 2021 22:35:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8769861606 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 763D96B0085; Fri, 25 Jun 2021 18:35:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ED0A6B0087; Fri, 25 Jun 2021 18:35:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5673C6B0088; Fri, 25 Jun 2021 18:35:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 21E6A6B0085 for ; Fri, 25 Jun 2021 18:35:02 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2F99C181AF5E6 for ; Fri, 25 Jun 2021 22:35:02 +0000 (UTC) X-FDA: 78293702844.30.6B006E3 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf11.hostedemail.com (Postfix) with ESMTP id 6BF62200106B for ; Fri, 25 Jun 2021 22:34:59 +0000 (UTC) IronPort-SDR: EgHVgF2vpysbhvOYDdFA+FJcH6uFjxSnM/sAqDnsZviw0pi8WeDFc5Bzo2g4zd+TOhPkzEwxjM Tuf4bupmrStw== X-IronPort-AV: E=McAfee;i="6200,9189,10026"; a="195045654" X-IronPort-AV: E=Sophos;i="5.83,300,1616482800"; d="scan'208";a="195045654" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 15:34:50 -0700 IronPort-SDR: M8WjOP6e8g6Fj5rht8Kq3iOotrgXQQM8Ukh0R3przq8MHn2OmXJuxOFh/fxss7kl/IZZ8UqXdx FX+HaaVFQrLw== X-IronPort-AV: E=Sophos;i="5.83,300,1616482800"; d="scan'208";a="481983698" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 15:34:50 -0700 Date: Fri, 25 Jun 2021 15:34:50 -0700 From: Ira Weiny To: Michael Ellerman Cc: Dave Hansen , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, "Shutemov, Kirill" , Benjamin Herrenschmidt , Catalin Marinas , Will Deacon , "Aneesh Kumar K.V" , Nicholas Piggin Subject: Re: [LSF/MM TOPIC] Impact on core mm from new hardware features Message-ID: <20210625223449.GC2799309@iweiny-DESK2.sc.intel.com> References: <51d3010b-6324-2441-42c0-27bb536c897d@intel.com> <87y2ayyy1h.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2ayyy1h.fsf@mpe.ellerman.id.au> User-Agent: Mutt/1.11.1 (2018-12-01) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6BF62200106B X-Stat-Signature: b47cko6uoo9mw1f6gy84hi65bz4k41qy Authentication-Results: imf11.hostedemail.com; dkim=none; spf=none (imf11.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ira.weiny@intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-HE-Tag: 1624660499-432324 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 Fri, Jun 25, 2021 at 09:38:18PM +1000, Michael Ellerman wrote: > Dave Hansen writes: > > I'd like to have a session about new hardware features that may will > > have an impact on core memory management. This session would have two > > goals: one to ensure that the OS-agnostic MM crowd understands what the > > architectures are going to be throwing their way. Second, that the > > different arch-specific folks can look for commonalities which could > > enable shared infrastructure. I'm interested in this subject. > > > > There should be enough x86 folks around, but I'd love to hear from the > > ARM and powerpc people as well. > > Cc += Aneesh and Nick > > I can't think of anything publicly announced for Power that will have a > big impact on core mm, but Nick & Aneesh might have ideas. > > cheers > > > Here are a few mostly Intel-specific things I'd like to discuss. > > However, all of these either have analogs on other architectures or are > > implemented by other x86 vendors. > > > > * Shadow Stacks - requires new Copy-on-Read memory type. Creates > > application mappings which are effectively PROT_NONE, but which are > > implicitly accessible by the hardware. > > * Linear Address Masking (LAM) - Similar to ARM's Top Byte Ignore > > (TBI). Repurpose some virtual address bits to store metadata. Intel > > implementation can sacrifice user address space. Offloads some of > > the work the compiler does in ASAN implementations. > > * Supervisor Protection Keys - Extends Memory Protection Keys (pkeys) > > to kernel mappings. I'd be more than happy to share what I've tried to do to make this support generic. Ira > > * TDX - VMs that don't trust the hypervisor. Requires unmapping guest > > memory from userspace and possibly the host kernel. > > > >