On Thu, Aug 14, 2025, Kai Huang wrote: > On Thu, 2025-08-14 at 11:00 -0700, Sean Christopherson wrote: > > > > > + */ > > > > > + tdx_cpu_flush_cache(); > > > > > > > > IIUC, this can be: > > > > > > > > if (IS_ENABLED(CONFIG_KEXEC)) > > > > tdx_cpu_flush_cache(); > > > > > > > > > > No strong objection, just 2 cents. I bet !CONFIG_KEXEC && CONFIG_INTEL_TDX_HOST > > > kernels will be the minority. Seems like an opportunity to simplify the code. > > > > Reducing the number of lines of code is not always a simplification. IMO, not > > checking CONFIG_KEXEC adds "complexity" because anyone that reads the comment > > (and/or the massive changelog) will be left wondering why there's a bunch of > > documentation that talks about kexec, but no hint of kexec considerations in the > > code. > > I think we can use 'kexec_in_progress', which is even better than > IS_ENABLED(CONFIG_KEXEC) IMHO. I don't think that will accomplish what you want. E.g. kvm-intel.ko is unloaded after doing TDX things, while kexec_in_progress=false, and then some time later a kexec is triggered. In that case, stop_this_cpu() will still get stuck doing WBINVD.
