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 A3449C83F09 for ; Wed, 9 Jul 2025 09:38:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 441E16B00B8; Wed, 9 Jul 2025 05:38:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4194F6B00B9; Wed, 9 Jul 2025 05:38:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32F0B6B00BA; Wed, 9 Jul 2025 05:38:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 221ED6B00B8 for ; Wed, 9 Jul 2025 05:38:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A0F621CBA63 for ; Wed, 9 Jul 2025 09:38:55 +0000 (UTC) X-FDA: 83644227030.24.9D0D88B Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf10.hostedemail.com (Postfix) with ESMTP id 5454EC0010 for ; Wed, 9 Jul 2025 09:38:53 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jv4SKJe4; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf10.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752053933; 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=iTjg11PNs46bwm8oR6jXefoqxrYKQ8yz6NZBhczfifo=; b=n8118MyH4fRTNaNaabJuw1824HF8q5nox2agHAZS6j9UVYjgjE96KLqKt0GLvjlTaxeWbD DduFW+F8aMo9QAfSm/k15Fol+ee6rhIYEsYhT5xFcA7hE6RLDxT/S/TvYtPRyCTLOYHkK9 n1KnTX/bg7jR1CEHiRdtw1ZgfaQiO70= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752053933; a=rsa-sha256; cv=none; b=k+/9UYYOpPoft/wybHrlkgqHPvaE96HKYCIAE6yiGxt5MaeWFwSEMo086YrJ3u6iorHbXB /WDAVQQna24aqISjwaioYcoPEORH6sDjI+KJm0MKagfmfVUJHWT4GSNYqvCC2NbKgnT2Yg rj461Qt5uVRLa9IRokmTe1PFr3SRIAg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jv4SKJe4; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf10.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752053933; x=1783589933; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xYZjRqgkPOL2LqzqY+U3wd+rmN7x/AzvRlTH/XIY5I8=; b=jv4SKJe4UYsAqq+uh2+AJgayG8Vu+ABjn6OHaEdf4DmhDPlDNQuXFMpq HStX8jg748z+EsJoGIvsgc5Id/oZloSWqPPVHNcNvbF0R91aUGOKde9Pe rTtc54W/BJT4vAylOcuLu1F9W+nb1Fhyh/qmrCXDeXiXb/IFkNhd9AUmJ 9PT7xGIpqV2aUYcwo6c2G7yTSmGPdCYAOGXKmk3GwVcKrtRJw4XFHyMmp vn11kuEMHBg5lKZdw9aEII8s0bNHnQYA7l42wtGX1gmRDgtUcqW4puqso dcHJb176/0aE92QRjVWFK1xiW1iDu8JJY/OINtsR9Q9pQ/uNIIVEdMAZV A==; X-CSE-ConnectionGUID: vIejLOE/Qf2lkeToW2IUZQ== X-CSE-MsgGUID: dw/Id7nNSGOOUR2hxzni7g== X-IronPort-AV: E=McAfee;i="6800,10657,11487"; a="54452039" X-IronPort-AV: E=Sophos;i="6.16,298,1744095600"; d="scan'208";a="54452039" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2025 02:38:52 -0700 X-CSE-ConnectionGUID: gXEO+CXSSgqC5YZ2O8fG+g== X-CSE-MsgGUID: 8CthuCcFTnOtmJIMMxE+9g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,298,1744095600"; d="scan'208";a="155366162" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa007.fm.intel.com with ESMTP; 09 Jul 2025 02:38:41 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id D42A01B7; Wed, 09 Jul 2025 12:38:39 +0300 (EEST) Date: Wed, 9 Jul 2025 12:38:39 +0300 From: "Kirill A. Shutemov" To: Sohil Mehta Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin , Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , 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, linux-mm@kvack.org Subject: Re: [PATCHv9 04/16] x86/cpu: Defer CR pinning setup until core initcall Message-ID: References: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> <20250707080317.3791624-5-kirill.shutemov@linux.intel.com> <9340dc9e-bd4d-450e-aa9b-b6b6829eab32@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9340dc9e-bd4d-450e-aa9b-b6b6829eab32@intel.com> X-Rspam-User: X-Rspamd-Queue-Id: 5454EC0010 X-Rspamd-Server: rspam03 X-Stat-Signature: t61h37ttxy1iwzz6d6sb1xsai5rzicfi X-HE-Tag: 1752053933-345230 X-HE-Meta: U2FsdGVkX19IqFrsdkEGJHNObMlvOSbp9iQfKeFChAYbRIgUK+NHlVYuooseWCRY0cv9EvwXDATS4Ku4TlVciR9cfceIr++3NAigwiFM/suZXlIOKw3G6FV10sGKOMY69luitnnV/nxAGxEJoTua2CBoCoDA3C7bQns7jPsfTN2x7coUBLbcqW2M7+qgUTbdfe+gFEBsE0GcsyYoK+kEOXxQQ0qE5NLQ7FcgP17i2bZut8JV0l3+P8bM7GujqqoB1ASmkdpAGG1yOauEQGAnz4UPIIG8HTZG8xVMPVzHCgp/QX7AUh6RFQt4tvN4yH6+ldG1p1V3k3n4eyeVGM6L5RzacCHUkS+JFpoFtgBKLIFAb8SrYdgDQxzBk7W+GKDKev6WX4mq7BXIDikNyYUagVJ4xHkqgILwOo0g7TVzH4TySNoMvkyD8WP+bybV7fwTRKV9tS0510lvxFZpJQVTeJ9Cn3gtDTXK4rmLSy/2u+XGqENPBGFep/5kSmHuhd6lbrNRXZGKrBYxOtfnD9T8RM46gUWw4w2lZ7CZrG05VgaMpTe4qUNDxrsskVusE8r75v7OLoeqM2oUrYR/m2ce2/xkgRrgbXTT8SNGcLYzzk0Ym5yfV1zTFHHxCeizZNhy8fj0yWkL67m6ZwVMkG4ZSTBKSQ87DZF4R49VsAt58mcdZMMnxTucKEe1QXvD/ZXyHsepEfNpBC9TEjVNNHEfdEFOuhBN3fOg5Wea7jTCc9SjLjg9fXPdD1OnnFjKok8gFzID+nreM2PEiksj/qi8L6v0w0ZnW0sJjyXkLzH6XBeZc+nsN7Aar8Xvt2LlqM0fFa+irN8uyBOBr3JGxOwnGzGlBCE9dcR1Sq6O9Dog3e1rKQroxTR4K6e4pSm5wxIDFUUQTLin0KWPk+qD8HcAxmSblQIBSWQNrB27TZtdSEqJhyF2W1ZO0V4lsofUijYAuQiC0rESjwCnZjDPAO8 T6BmCY6v B3XkE+IwmAVyD/0826vla0xvq8abwiJ2wc98zWVEdF+p5Cjww2sEJOK6OIKBKPjUG2P9H4SrAqzPbwA1LU1ruq4MYCSD16RWL+cqGmw5JfvCeqTDZ2MNqjUg2gueTMTItA4OrWQlOXwGUmDrNRcksZsU7vCHKq+Y1M5OBh+v0JX0xSyNLUlBPqQHRN2JEpkrg9V2sYE9P2hYy3P2ULEPXqMLlesud01kN9hFwih6MIAjnbog0Zjr2SxSExQ== 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 08, 2025 at 06:19:03PM -0700, Sohil Mehta wrote: > On 7/7/2025 1:03 AM, Kirill A. Shutemov wrote: > > From: Alexander Shishkin > > > > In order to map the EFI runtime services, set_virtual_address_map() > > needs to be called, which resides in the lower half of the address > > space. This means that LASS needs to be temporarily disabled around > > this call. This can only be done before the CR pinning is set up. > > > > Instead of moving setup_cr_pinning() below efi_enter_virtual_mode() in > > arch_cpu_finalize_init(), defer it until core initcall. > > > > Wrapping efi_enter_virtual_mode() into lass_stac()/clac() is not enough > > because AC flag gates data accesses, but not instruction fetch. Clearing > > the CR4 bit is required. > > > > I think the wording might need to be reordered. How about? > > In order to map the EFI runtime services, set_virtual_address_map() > needs to be called, which resides in the lower half of the address > space. This means that LASS needs to be temporarily disabled around > this call. > > Wrapping efi_enter_virtual_mode() into lass_stac()/clac() is not enough > because AC flag gates data accesses, but not instruction fetch. Clearing > the CR4 bit is required. > > However, this must be done before the CR pinning is set up. Instead of > arbitrarily moving setup_cr_pinning() after efi_enter_virtual_mode() in > arch_cpu_finalize_init(), defer it until core initcall. > > Other than that, > Reviewed-by: Sohil Mehta Okay, looks good, thanks! -- Kiryl Shutsemau / Kirill A. Shutemov