From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB5CB3093DE; Fri, 6 Feb 2026 19:19:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770405577; cv=none; b=gx2HOnMpEQteEn9RTYGZQcnbdpLoS0gr8h5XzYgwRT7tbkkAKfWcCpPKY9yXi7RTpIQ0WyjyA0m18pV3P00bVpfciskR34m7dRTR1G1lZG3pzyax+wC4mhG/fFScivVAwOOkrIFNas0SMfuizj/NX/7lilfYP/lcmhn0xlTaQJw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770405577; c=relaxed/simple; bh=otLnrbw7BdRmEwMu22GOgdmD5WAOxTne253r8HWDLKI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uRI25jCJmiG1+nnlOasOi2lIYkmjX3STtFJkg+KhJh9TFfWHvtQ5EA9IZvBEujaG6PeB/LQRJkPe4KMkZmFHYmpOesi+wVPuE/0fAwh4TuI80zraA6Bjg6IV1gqSEG9iwMKjLTLN1E3H1yNnMSxuoDW02B9lXPtiiYDTDombCc0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TFcL0oW5; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TFcL0oW5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1770405577; x=1801941577; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=otLnrbw7BdRmEwMu22GOgdmD5WAOxTne253r8HWDLKI=; b=TFcL0oW5JtBOdpFVpNrD6AyS+se/MicRetuNF/PC8qK06Q/KiTm3fuMA PF4752SyWIulXJZC6m5T4i0UfzLc252t3btaOQJfD8RsAj7gYbgBJHSX5 Wy9TetHgG0KqHcp1OS2zHHkcSRFUJ2BPOyvbCWSnwSnjQNTvVZu8o++Iq hfbDgcniK3Ttyg0OS7ROPB1uYNYo6WPUdocBNl2quP5OXh9H0PumlmF/n R0c8kh5nqUg+FWKw74Rr4CLO6oGCJENot/o5WIbYUPnkL5wamA26S9k9e RDLSf//W7kMcFbDPEf3XjCy4yCTF6TndhNOj21GzD5ibUzYg3X50r9ZjJ Q==; X-CSE-ConnectionGUID: GJBPH2KxTf2ptG3D5WvspQ== X-CSE-MsgGUID: OdKzRkmFSVKU4YnGvfYOTw== X-IronPort-AV: E=McAfee;i="6800,10657,11693"; a="74219915" X-IronPort-AV: E=Sophos;i="6.21,277,1763452800"; d="scan'208";a="74219915" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2026 11:19:36 -0800 X-CSE-ConnectionGUID: D40UAiYaQGSs9p6zDhiRUg== X-CSE-MsgGUID: Sn8/cLx7RLqzgWLf5pDzPA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,277,1763452800"; d="scan'208";a="210992383" Received: from aschende-mobl.amr.corp.intel.com (HELO [10.125.111.156]) ([10.125.111.156]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2026 11:19:36 -0800 Message-ID: Date: Fri, 6 Feb 2026 11:19:35 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/smp: Set up exception handling before cr4_init() To: "Xin Li (Intel)" , linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com, sohil.mehta@intel.com, nikunj@amd.com, thomas.lendacky@amd.com, seanjc@google.com, stable@vger.kernel.org References: <20260206185035.1250577-1-xin@zytor.com> From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: <20260206185035.1250577-1-xin@zytor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > + /* > + * AP startup assembly code has setup the following before calling > + * start_secondary() on 64-bit: > + * > + * 1) CS set to __KERNEL_CS. > + * 2) CR3 switched to the init_top_pgt. > + * 3) CR4.PAE, CR4.PSE and CR4.PGE are set. > + * 4) GDT set to per-CPU gdt_page. > + * 5) ALL data segments set to the NULL descriptor. > + * 6) MSR_GS_BASE set to per-CPU offset. > + * 7) IDT set to bringup IDT. > + * 8) CR0 set to CR0_STATE. > + * > + * So it's ready to setup exception handling. > + */ > cpu_init_exception_handling(false); This is fine because very little of that ^ is ever going to change. It's not great that it duplicates the assembly logic, but it's good documentation I guess. > + /* > + * Ensure bits set in cr4_pinned_bits are set in CR4. > + * > + * cr4_pinned_bits is a subset of cr4_pinned_mask, which includes > + * the following bits: > + * X86_CR4_SMEP > + * X86_CR4_SMAP > + * X86_CR4_UMIP > + * X86_CR4_FSGSBASE > + * X86_CR4_CET > + * X86_CR4_FRED > + */ > + cr4_init(); I'm not as big of a fan of this comment. The next pinned bit that gets added will make this stale. Could we try to make this more timeless, please? I'm also not sure I like the asymmetry of this between the boot and secondary CPUs. On a boot CPU, CR4.SMEP will get set via identify_boot_cpu() and eventually setup_smep(). On a secondary CPU, it'll get set in cr4_init() and *not* in setup_smep(). This asymmetry is (I think) part of what the root of the problem is here and how this bug came to be. I really think the current pinning behavior is too invasive. It has zero benefit to be pinning CR bits this early in bringup. It's only causing pain. I _really_ think we need a defined per-cpu point where pinning comes into effect. Marking the CPU online is one idea. Thoughts?