Re: [PATCH v2 2/5] x86/virt/tdx: Pull kexec cache flush logic into arch/x86

[Sean Christopherson <seanjc@google.com>]

On Tue, Mar 31, 2026, Rick P Edgecombe wrote:
> On Tue, 2026-03-31 at 12:22 -0700, Sean Christopherson wrote:
> > > -
> > > -#ifdef CONFIG_KEXEC_CORE
> > > -void tdx_cpu_flush_cache_for_kexec(void)
> > > -{
> > > -	lockdep_assert_preemption_disabled();
> > 
> > Is there a pre-existing bug here that gets propagate to tdx_shutdown_cpu()? 
> > When called from kvm_offline_cpu(), preemption won't be fully disabled, but
> > per-CPU access are fine because the task is pinned to the target CPU.
> > 
> > See https://lore.kernel.org/all/aUVx20ZRjOzKgKqy@google.com
> 
> Yes. And actually it got hit during development of this series. This patch will
> conflict with the fix:
> https://lore.kernel.org/lkml/20260312100009.924136-1-kai.huang@intel.com/
> 
> Oh, you acked it actually. But I was under the impression that after this patch
> here, the splat wouldn't be triggered. So it inadvertently fixes it.

Ah, that's why I was a bit confused.  I was assuming tdx_shutdown_cpu() was a
cpuhp callback, but it's actually an IPI callback.

Hmm, isn't this patch wrong then?  Ah, no, the changelog says:

  However, WBINVD is already generally done at CPU offline as matter of course.
  So don't bother adding TDX specific logic for this, and rely on the normal
  WBINVD to handle it.

What's the "normal" WBINVD?  At the very least, tdx_offline_cpu() should have a
comment that explicitly calls out where that WBVIND is.  I assume you're referring
to the wbinvd() calls in things like hlt_play_dead()?

But unless the WBINVD is actually costly, why bother getting fancy?

> But that other patch is much more backport friendly.