Message ID | 20230213234836.3683-2-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2648977wrn; Mon, 13 Feb 2023 15:56:51 -0800 (PST) X-Google-Smtp-Source: AK7set8cLM419Wp862qLaXLNDX3SvTxIZEzZZCn54J9gQuZ5BB+/v1SERWAJ+6kSMsPrVSXczsuR X-Received: by 2002:a17:906:8306:b0:879:36b4:486 with SMTP id j6-20020a170906830600b0087936b40486mr913814ejx.13.1676332611538; Mon, 13 Feb 2023 15:56:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676332611; cv=none; d=google.com; s=arc-20160816; b=opd8jQ2QZgmJRCCwZHY61Zg3BVHuhdkt8oo3cJSFP6LDhV3jlSs6YfoM0yXrZw1t0V oQfvvJTqtOnYjhORdqdlCJxpb1T8cBMZRI3Mfq9zxApIPMFhKGodlrYVOR3XpBHQ22z9 SSCumMpxFJqCDW0WtkGvwb8RvP2ScovOJndj5kEmVHUV4XI+8rTHaUthHXmGwtfgogjK 5IU7BZR/6TgV43s2r3aNmhCxbjDQjTuch3t+aksYVVXJMcJTwdjYYqYaE9aFu6C0Wj2q DOTC8h2GWQeOBlFYNtc5+t9gN30KP3UA9/mycd1rCmRcPO6Jx4rT5tCywq5fkXoyeqhM hmdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=n4WkeoAsEkPJgJL+pfHPB8by+xno+wnCiToA8Ijb/10=; b=ZCsctvdO4gOfYX3lBUGst/vX4kH6MjqluxxFnaHMLjnYmx2YFCv9UkOvmgdcttdmwW Co1ZVWB3LJU/FwKYU8U5rax//2CRGsgcwBIDU/d/y9rCgcMuU0R96QjLoqY8CBU6cYQV FcizzBQ+JIKp7mjoKJgQPK4GvehVQdEVq8mUrbHw9SJobZlsbJHBTG5rURSD6GMZ2HSN h64FV4Q7v8xFqISeIeN9Q5X8PQRzPSpn3IV1acOVEz8MPXQS3kTddcaPN9lG8/nPQjpL ehhKvl3rlSCOHPZUZ4+iBE90J3Fy/9VzD5YBCHbzGhmGQO3cIU+e243bc7Lvwf77VboV p7Aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DEU4gkRe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m27-20020a170906599b00b00887dadb95e2si15288968ejs.711.2023.02.13.15.56.28; Mon, 13 Feb 2023 15:56:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DEU4gkRe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231226AbjBMXtP (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Mon, 13 Feb 2023 18:49:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231214AbjBMXtK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 13 Feb 2023 18:49:10 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3B6D193DC for <linux-kernel@vger.kernel.org>; Mon, 13 Feb 2023 15:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676332143; x=1707868143; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0x8prcfOkEmACeYEiOgHUm+WyjDXkIRz6t1uNF7BUGU=; b=DEU4gkRe/LLVPz4mbmoDkRzEjfxFbx3I8SLNirxLNL96qdWaDD15dR26 lkOcvo9DsLQEL09c7WQdokTlK3piGVyHkYW8iQreseYHUnBrjt85LtUCS fQDksFjPUHK5tEtSPPMRj42RwY3I/Fb5BdFmopd2plqZ/bKHuOt+Pcu3Z 9WmOx09Em9RfwgCtJHM33EyyvQWtQcaK4r5DrGUru1h6WCMDLyPpKcrz7 Q0585VAobnBCGTTm/xwZrgn9gwVHC5fvRxUEwjMosn+HwK2Z6pyZimU0M 1fFa63JS+f3I/qrdhd/F/3HFpfpYpGVFMGMUaQEcmAPVaq3IAc7QDAr1c g==; X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="395645603" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="395645603" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 15:48:48 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="732672802" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="732672802" Received: from iannetti-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.49.216]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 15:48:46 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id 62E0010CA34; Tue, 14 Feb 2023 02:48:43 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave.hansen@intel.com>, Borislav Petkov <bp@alien8.de> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Thomas Gleixner <tglx@linutronix.de>, Isaku Yamahata <isaku.yamahata@intel.com>, x86@kernel.org, linux-coco@lists.linux.dev, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCH 1/2] x86/kexec: Preserve CR4.MCE during kexec Date: Tue, 14 Feb 2023 02:48:35 +0300 Message-Id: <20230213234836.3683-2-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230213234836.3683-1-kirill.shutemov@linux.intel.com> References: <20230213234836.3683-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757762144263195444?= X-GMAIL-MSGID: =?utf-8?q?1757762144263195444?= |
Series |
Kexec enabling in TDX guest
|
|
Commit Message
Kirill A. Shutemov
Feb. 13, 2023, 11:48 p.m. UTC
TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads
to #VE.
Preserve the flag during kexec.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
arch/x86/kernel/relocate_kernel_64.S | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote: > TDX guests are not allowed to clear CR4.MCE. Attempt to clear it > leads > to #VE. > > Preserve the flag during kexec. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> I wonder whats going on with the pre-existing switching between eax and rax in this code for the cr0 and cr4 manipulations. Do you know what the reason is? Also, for a simple non-tdx kexec regression test: Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
On Thu, Feb 16, 2023 at 01:49:39AM +0000, Edgecombe, Rick P wrote: > On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote: > > TDX guests are not allowed to clear CR4.MCE. Attempt to clear it > > leads > > to #VE. > > > > Preserve the flag during kexec. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > I wonder whats going on with the pre-existing switching between eax and > rax in this code for the cr0 and cr4 manipulations. Do you know what > the reason is? 32-bit ORs and ANDs save one byte per instruction. And there's no 32-bit MOV to/from control registers in 64-bit mode. > > Also, for a simple non-tdx kexec regression test: > Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Thanks!
On Thu, 2023-02-16 at 12:43 +0300, Kirill A. Shutemov wrote: > On Thu, Feb 16, 2023 at 01:49:39AM +0000, Edgecombe, Rick P wrote: > > On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote: > > > TDX guests are not allowed to clear CR4.MCE. Attempt to clear it > > > leads > > > to #VE. > > > > > > Preserve the flag during kexec. > > > > > > Signed-off-by: Kirill A. Shutemov < > > > kirill.shutemov@linux.intel.com> > > > > I wonder whats going on with the pre-existing switching between eax > > and > > rax in this code for the cr0 and cr4 manipulations. Do you know > > what > > the reason is? > > 32-bit ORs and ANDs save one byte per instruction. And there's no 32- > bit > MOV to/from control registers in 64-bit mode. Oh right, I think I recall now. There is a 64 bit AND in the CR0 piece here too, which of course is outside of these changes. But otherwise, it's not clear from the patch what the implications are of leaving CR4.MCE set for the non-TDX environment. I see in head_64.S it will clear it during boot if the kernel doesn't support machine check. So it leaves a little window where CR4.MCE is set where it wasn't before. The piece in head_64.S talks about how an #MC will crash the system if it happens before the machine check stuff is fully setup anyway, so it doesn't hurt to leave it on. Is that the reasoning for this change as well? If so it might help to add a little more about the reasoning in the commit log.
diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index 4a73351f87f8..18f19dcc40e9 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -145,8 +145,12 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped) * Set cr4 to a known state: * - physical address extension enabled * - 5-level paging, if it was enabled before + * - Preserve MCE, if it was set. Clearing MCE may fault in some + * environments. */ - movl $X86_CR4_PAE, %eax + movq %cr4, %rax + andl $X86_CR4_MCE, %eax + orl $X86_CR4_PAE, %eax testq $X86_CR4_LA57, %r13 jz 1f orl $X86_CR4_LA57, %eax