From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 96EB754777 for ; Fri, 29 Mar 2024 15:21:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711725706; cv=none; b=tdVbdZdi+xpOCva930vqQIrqS+RbUA5W/nDlSdBgL6sNYZeYFppNvvlharS6q6mB9Uo5q8uXAFxoZzF5CcaDYDMsHbk5T37wjV9CR2juyd4pAl58s1PE0C2wImtu2c57HKWDDLjjuFZT9l7s8hvVvzItO5sbHojgJoBiBjcfOy8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711725706; c=relaxed/simple; bh=xIhz1fc0gd8bUoWk1Yba/XGwSpCgbpumuPmPXecDCog=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mOC2Ja4MNT8+TRA92k8gQ9GRojGKXvs9MXKtdsJyqspgxIZLW1bZFozsf/svGYyOtuqgxNMw+Hsi8yW8oC0U5ySWSFXL3dgGfFEF6YCUn22/tyAn3u5sVvJ7PR7HlsOy1SXyxSjrk3OBe3v+vLZwuinwghFO/0O23xwd0jqnmpU= 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=ZJKtspY0; arc=none smtp.client-ip=198.175.65.11 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="ZJKtspY0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711725702; x=1743261702; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=xIhz1fc0gd8bUoWk1Yba/XGwSpCgbpumuPmPXecDCog=; b=ZJKtspY0jsFuTnIcc6aqcoRMvX4hnpNMkAHa5QnXVSPxFrU2xUe//mUN hPzYbvxgu2NUyV4XP5JArSs4yuSM0ERKdwcEyprikmgz0swbmV9wz4mS+ XIjqWkYXyC9zekGb4Vd1YEgKQRg20DtwbovEfwHUBn+v2GEC2+APKRcdi G5M7AzgQr0tZoa6ty6lgxXeE5mDCm/JM8m/n8aMFIJs/yU74dOpgJcjjr AJJj7vsVCKNbSuyQhu0ytbdvf1eYFV4Yc7C+W3lCCwTsdvtcWVFwus49l LzBsCvWV9PHcLziiOrO2G4JjCJv157ckdYjL9RIwcycHttjXxZiQoWhm9 Q==; X-CSE-ConnectionGUID: 265PdfyTSxaDag1RaOW+xA== X-CSE-MsgGUID: MXk0ti4/TTm+bcRIK4ycZA== X-IronPort-AV: E=McAfee;i="6600,9927,11028"; a="17472613" X-IronPort-AV: E=Sophos;i="6.07,165,1708416000"; d="scan'208";a="17472613" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2024 08:21:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,165,1708416000"; d="scan'208";a="17636665" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.224.7]) ([10.124.224.7]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2024 08:21:36 -0700 Message-ID: Date: Fri, 29 Mar 2024 23:21:32 +0800 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv9 05/17] x86/kexec: Keep CR4.MCE set during kexec for TDX guest To: "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "Rafael J. Wysocki" , Peter Zijlstra , Adrian Hunter , Kuppuswamy Sathyanarayanan , Elena Reshetova , Jun Nakajima , Rick Edgecombe , Tom Lendacky , "Kalra, Ashish" , Sean Christopherson , "Huang, Kai" , Baoquan He , kexec@lists.infradead.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org References: <20240325103911.2651793-1-kirill.shutemov@linux.intel.com> <20240325103911.2651793-6-kirill.shutemov@linux.intel.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <20240325103911.2651793-6-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/25/2024 6:38 PM, Kirill A. Shutemov wrote: > TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads > to #VE. Will we consider making it more safe and compatible for future to guard against X86_FEATURE_MCE as well? If in the future, MCE becomes configurable for TD guest, then CR4.MCE might not be fixed1. > Use alternatives to keep the flag during kexec for TDX guests. > > The change doesn't affect non-TDX-guest environments. > > Signed-off-by: Kirill A. Shutemov > Reviewed-by: Kai Huang > Reviewed-by: Thomas Gleixner > --- > arch/x86/kernel/relocate_kernel_64.S | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S > index 56cab1bb25f5..e144bcf60cbe 100644 > --- a/arch/x86/kernel/relocate_kernel_64.S > +++ b/arch/x86/kernel/relocate_kernel_64.S > @@ -5,6 +5,8 @@ > */ > > #include > +#include > +#include > #include > #include > #include > @@ -145,12 +147,15 @@ 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 > + * - Machine check exception on TDX guest. Clearing MCE is not allowed > + * in TDX guests. > */ > movl $X86_CR4_PAE, %eax > testq $X86_CR4_LA57, %r13 > jz 1f > orl $X86_CR4_LA57, %eax > 1: > + ALTERNATIVE "", __stringify(orl $X86_CR4_MCE, %eax), X86_FEATURE_TDX_GUEST > movq %rax, %cr4 > > jmp 1f