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 73BC5C43334 for ; Wed, 15 Jun 2022 15:54:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE4C26B0071; Wed, 15 Jun 2022 11:54:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B94546B0072; Wed, 15 Jun 2022 11:54:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A354F6B0074; Wed, 15 Jun 2022 11:54:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 912E66B0071 for ; Wed, 15 Jun 2022 11:54:39 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 62DDE202EE for ; Wed, 15 Jun 2022 15:54:39 +0000 (UTC) X-FDA: 79580917878.03.A85FBFF Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf22.hostedemail.com (Postfix) with ESMTP id D1C27C0011 for ; Wed, 15 Jun 2022 15:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655308476; x=1686844476; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qDm82Al5RdY5yk2Sk8uLzqG18X3zOv/St63Fun4bYIA=; b=VP6yeWoSsGTucRRysjSIUBPmzjpDO3solq2OY7A0YQvPk4S8OpmRw/wb TN/ippkcS8W6KafxFfOqLM/9LkoISKW0EmC9mukZrXoL1M3Btor31l4Fw /OvBfajJ+znxlvLhVswrEM5Rv3OgHNtfxdkgeWE71OMWskr/gueFBRsQy ES1mtx3qIxKnSEImb7PajtUWieMwzNwE34Zrkbrd66zr+Lmt3kDxqsn2t a4YaNrR6fKE19wlvVzxkRnTjDReka0CHuktklPZA42urpTkPnUsiZbVqE QKaJkG4eqZZTVFb6Dve+cQSZdd7SacVrajN7rmNWwmO6IlydudJMYaGhf A==; X-IronPort-AV: E=McAfee;i="6400,9594,10379"; a="365358203" X-IronPort-AV: E=Sophos;i="5.91,302,1647327600"; d="scan'208";a="365358203" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2022 08:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,302,1647327600"; d="scan'208";a="652727965" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga004.fm.intel.com with ESMTP; 15 Jun 2022 08:54:32 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 67A85109; Wed, 15 Jun 2022 18:54:36 +0300 (EEST) Date: Wed, 15 Jun 2022 18:54:36 +0300 From: "Kirill A. Shutemov" To: "Edgecombe, Rick P" Cc: "peterz@infradead.org" , "Lutomirski, Andy" , "dave.hansen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "kcc@google.com" , "andreyknvl@gmail.com" , "ak@linux.intel.com" , "dvyukov@google.com" , "x86@kernel.org" , "ryabinin.a.a@gmail.com" , "glider@google.com" Subject: Re: [PATCHv3 4/8] x86/mm: Handle LAM on context switch Message-ID: <20220615155436.5fvosccsqbpscli4@black.fi.intel.com> References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-5-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655308478; a=rsa-sha256; cv=none; b=qn1mWfxaTxD1uxeEcIX82pWSwMIvA3vr2bIfU+sHlqHFylO+m6SiufXtQhoUc6Jml19R0x R7snzO72z90cM7s4j0kbF2qaES49ANAsLANBUFTzny9upLLV+wBsDik7gk5p2IKJPqnF2Z oVA3hL6btejHP6RByYXSfdwVW5Gp7Bk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655308478; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ys82iWNSi8ZJ8pUs1Ex22X0NWOFLC0OPBOrVuUR0cmk=; b=W7Ra/90+Asfulc4es7VYE5Tr9YuJ3vr/UeJAvo70w55n4ehGNIZD+MAUFhJnSCRC/2b0s9 /Fxmo7CGp04xz4HUTzZHigToeVC5EX5rhUZGM1RlgprAgV6Xv6N+c2XaLE0zoZM6ODPtfG 2LwMdHW9TqTqirG+Gc5iYCv8hkaKZaw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VP6yeWoS; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VP6yeWoS; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D1C27C0011 X-Stat-Signature: gi7nehzi3fe59xwxjj5yz38anh5ib3cu X-HE-Tag: 1655308476-133137 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 10, 2022 at 11:55:02PM +0000, Edgecombe, Rick P wrote: > On Fri, 2022-06-10 at 17:35 +0300, Kirill A. Shutemov wrote: > > @@ -687,6 +716,7 @@ void initialize_tlbstate_and_flush(void) > > struct mm_struct *mm = this_cpu_read(cpu_tlbstate.loaded_mm); > > u64 tlb_gen = atomic64_read(&init_mm.context.tlb_gen); > > unsigned long cr3 = __read_cr3(); > > + u64 lam = cr3 & (X86_CR3_LAM_U48 | X86_CR3_LAM_U57); > > > > /* Assert that CR3 already references the right mm. */ > > WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd)); > > @@ -700,7 +730,7 @@ void initialize_tlbstate_and_flush(void) > > !(cr4_read_shadow() & X86_CR4_PCIDE)); > > > > /* Force ASID 0 and force a TLB flush. */ > > - write_cr3(build_cr3(mm->pgd, 0)); > > + write_cr3(build_cr3(mm->pgd, 0, lam)); > > > > Can you explain why to keep the lam bits that were in CR3 here? It > seems to be worried some CR3 bits got changed and need to be set to a > known state. Why not take them from the MM? > > Also, it warns if the cr3 pfn doesn't match the mm pgd, should it warn > if cr3 lam bits don't match the MM's copy? You are right, taking LAM mode from init_mm is more correct. And we need to update tlbstate with the new LAM mode. I think both CR3 and init_mm should LAM disabled here as we are bringing CPU up. I'll add WARN_ON(). -- Kirill A. Shutemov