From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 206B820ADFC; Tue, 29 Oct 2024 23:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730245355; cv=none; b=GZHC4KZgnidN6HBF3JsjLc1euaWkr7gqVGtSawM3P4THQnC7xQ1SoalA1BLe9cEg712Ww94fjQq0RndkmKlLbMw6ICdUTqsQ9VeVBAhjMwGFZBIEgH+VZ6sxlejpyeDqA0yTAEnT4O882+7H/rCTLAs2+F1iaCA0AXAjxisaSBw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730245355; c=relaxed/simple; bh=s11/RSSNd5eLw5Fbc7WixTPocGJ75zsFhB1GD96i6gw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=T1+3ijbV9YTb/6d+rSsulk34AayLW21tgPRtF/5wDChkFo+2zH+JJslSl03GFjv1tT7QtTYRcY2nAhFfZOGtIfiyzKYctD8IpPr1G6yWsGap6Oh1m6wF2306crctVFMtgTpSAeJ4BYiitSMTqncbNFPzDygITWNmXp5k3ScMA/c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=aMMZ79vO; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="aMMZ79vO" Received: from [172.27.3.244] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 49TNfXGb592027 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 29 Oct 2024 16:41:33 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 49TNfXGb592027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024101701; t=1730245297; bh=s8jD91ycoelRAi31peFqxGDoUYOmCn36Gpqbgv/Oxb4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=aMMZ79vO/9CZL/+2Slxl7Uhe1SXLMkFhDSfSsStEsgaMp8Gw7t9Xj1QmkgNDQJkbK GRiop4Z2vAd3TZN51McsRNtKYCH4QO2rWitK7UlrERy3Es3Eq1JOzR1lBadKkGVI2C kNdo2+/4xiSiJoB8LqZTUb+Fau+LVAxt+/JgqAHfSF5oMysVhf81ha+bOInT11kzoW D1vj+IDEtjWBMJubKqo5Cg9Dc9eMlz+iFx3NYNFxIeBt3YUmuoa2Lax9ZApIrL6hde /4Aw4t8cndU3ktlpF3aRf4ezFRtme4aIKiRva8hGBH5CD9nc9one1XIhBQQi2uDVZ/ gXm8yAd+oR5jQ== Message-ID: <2e1c3685-6e6b-488d-ad8e-268193b13739@zytor.com> Date: Tue, 29 Oct 2024 16:41:33 -0700 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 v5 05/16] x86/cpu: Defer CR pinning setup until after EFI initialization To: "Luck, Tony" , "Hansen, Dave" , "Mehta, Sohil" , Alexander Shishkin , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , "Li, Xin3" , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , "Kirill A. Shutemov" , Alexey Kardashevskiy Cc: Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , "Huang, Kai" , Sandipan Das , Breno Leitao , "Edgecombe, Rick P" , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" References: <20241028160917.1380714-1-alexander.shishkin@linux.intel.com> <20241028160917.1380714-6-alexander.shishkin@linux.intel.com> <34dd023d-3ed5-4655-88be-14a7a300b91e@intel.com> <869c1545-8c94-4820-a861-fbc563056597@intel.com> Content-Language: en-US From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/29/24 16:18, Luck, Tony wrote: >>> Yeah, I was talking about 64-bit only. On 32-bit PAE a PGD maps 1/4 of >>> the address space which is totally unworkable for stealing. >> >> But it is also not necessary. > > So maybe we could make the 64-bit version of use_temporary_mm() > use some reserved address mapping to a reserved PGD in the upper > half of address space, and the 32-bit version continue to use "user" > addresses. It's unclear to me whether adding complexity here would be > worth it to remove the 64-bit STAC/CLAC text patching issues. > For 32 bits we can also simply use something further down in the hierarchy. It's not like we can afford to have the PGD be anything other than RWX on 32 bits. -hpa