linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>, "bp@alien8.de" <bp@alien8.de>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>
Cc: "seanjc@google.com" <seanjc@google.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"sagis@google.com" <sagis@google.com>,
	"Chatre, Reinette" <reinette.chatre@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>,
	"ashish.kalra@amd.com" <ashish.kalra@amd.com>,
	"Chen, Farrah" <farrah.chen@intel.com>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH v3 3/6] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum
Date: Thu, 26 Jun 2025 18:49:27 +0000	[thread overview]
Message-ID: <46b79a986eaaac6e413db2d6e7826c769f9dba6c.camel@intel.com> (raw)
In-Reply-To: <412a62c52449182e392ab359dabd3328eae72990.1750934177.git.kai.huang@intel.com>

On Thu, 2025-06-26 at 22:48 +1200, Kai Huang wrote:
> Some early TDX-capable platforms have an erratum: A kernel partial
> write (a write transaction of less than cacheline lands at memory
> controller) to TDX private memory poisons that memory, and a subsequent
> read triggers a machine check.
> 
> On those platforms, the old kernel must reset TDX private memory before
> jumping to the new kernel, otherwise the new kernel may see unexpected
> machine check.  Currently the kernel doesn't track which page is a TDX
> private page.  For simplicity just fail kexec/kdump for those platforms.
> 
> Leverage the existing machine_kexec_prepare() to fail kexec/kdump by
> adding the check of the presence of the TDX erratum (which is only
> checked for if the kernel is built with TDX host support).  This rejects
> kexec/kdump when the kernel is loading the kexec/kdump kernel image.
> 
> The alternative is to reject kexec/kdump when the kernel is jumping to
> the new kernel.  But for kexec this requires adding a new check (e.g.,
> arch_kexec_allowed()) in the common code to fail kernel_kexec() at early
> stage.  Kdump (crash_kexec()) needs similar check, but it's hard to
> justify because crash_kexec() is not supposed to abort.
> 
> It's feasible to further relax this limitation, i.e., only fail kexec
> when TDX is actually enabled by the kernel.  But this is still a half
> measure compared to resetting TDX private memory so just do the simplest
> thing for now.
> 
> The impact to userspace is the users will get an error when loading the
> kexec/kdump kernel image:
> 
>   kexec_load failed: Operation not supported
> 
> This might be confusing to the users, thus also print the reason in the
> dmesg:
> 
>   [..] kexec: not allowed on platform with tdx_pw_mce bug.
> 
> Signed-off-by: Kai Huang <kai.huang@intel.com>
> Tested-by: Farrah Chen <farrah.chen@intel.com>
> 

This does mean that kdump will not be allowed on these platforms if TDX is
configured in the BIOS, even if they don't set the kvm.tdx module param to
actually use it. Today it is not easy to accidentally turn on TDX in the BIOS,
so this would not usually happen by accident. Some future platforms might make
it easier, but today we don't support any kexec if TDX is configured today. So
this still opens up more capability than existed before. All considered, I think
it's a good direction.

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

  reply	other threads:[~2025-06-26 18:49 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 10:48 [PATCH v3 0/6] TDX host: kexec/kdump support Kai Huang
2025-06-26 10:48 ` [PATCH v3 1/6] x86/sme: Use percpu boolean to control wbinvd during kexec Kai Huang
2025-06-26 17:59   ` Edgecombe, Rick P
2025-06-26 18:42     ` Edgecombe, Rick P
2025-06-27  0:30       ` Huang, Kai
2025-06-30  7:09         ` Binbin Wu
2025-06-27  0:37     ` Huang, Kai
2025-06-27  0:39       ` Edgecombe, Rick P
2025-06-27  1:06         ` Huang, Kai
2025-06-27 15:08   ` Tom Lendacky
2025-06-30 11:35     ` Huang, Kai
2025-06-28 12:50   ` Borislav Petkov
2025-06-28 17:04     ` Tom Lendacky
2025-06-30 11:34       ` Huang, Kai
2025-06-30 11:34     ` Huang, Kai
2025-07-01 12:12       ` Borislav Petkov
2025-07-02  3:06         ` Huang, Kai
2025-06-26 10:48 ` [PATCH v3 2/6] x86/virt/tdx: Mark memory cache state incoherent when making SEAMCALL Kai Huang
2025-06-26 18:37   ` Edgecombe, Rick P
2025-06-26 23:36     ` Huang, Kai
2025-06-27  0:52       ` Edgecombe, Rick P
2025-06-27  1:47         ` Huang, Kai
2025-06-26 10:48 ` [PATCH v3 3/6] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Kai Huang
2025-06-26 18:49   ` Edgecombe, Rick P [this message]
2025-07-01  5:37   ` Binbin Wu
2025-07-02  3:12     ` Huang, Kai
2025-07-02  8:25   ` Chao Gao
2025-07-02  8:43     ` Huang, Kai
2025-07-02 22:16       ` Vishal Annapurve
2025-07-02 23:57         ` Edgecombe, Rick P
2025-06-26 10:48 ` [PATCH v3 4/6] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2025-06-26 18:49   ` Edgecombe, Rick P
2025-06-26 10:48 ` [PATCH v3 5/6] x86/virt/tdx: Update the kexec section in the TDX documentation Kai Huang
2025-06-26 18:51   ` Edgecombe, Rick P
2025-06-26 10:48 ` [PATCH v3 6/6] KVM: TDX: Explicitly do WBINVD upon reboot notifier Kai Huang
2025-06-27  0:01   ` Edgecombe, Rick P
2025-06-27  1:00     ` Huang, Kai
2025-07-01  6:09   ` Binbin Wu
2025-07-02  3:14     ` Huang, Kai
2025-07-02  7:54   ` Chao Gao
2025-07-02  9:22     ` Huang, Kai
2025-07-07 12:37     ` Huang, Kai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46b79a986eaaac6e413db2d6e7826c769f9dba6c.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=farrah.chen@intel.com \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).