Re: [PATCH v7 04/20] x86/virt/tdx: Add skeleton to initialize TDX on demand

[Thomas Gleixner]

On Tue, Nov 22 2022 at 10:02, Peter Zijlstra wrote:
> On Mon, Nov 21, 2022 at 01:26:26PM +1300, Kai Huang wrote:
>> +	cpus_read_unlock();
>> +
>> +	return ret;
>> +}
>
> Uhm.. so if we've offlined all the SMT siblings because of some
> speculation fail or other, this TDX thing will fail to initialize?
>
> Because as I understand it; this TDX initialization happens some random
> time after boot, when the first (TDX using) KVM instance gets created,
> long after the speculation mitigations are enforced.

Correct. Aside of that it's completely unclear from the changelog why
TDX needs to run the seamcall on _all_ present CPUs and why it cannot
handle CPU being hotplugged later.

It's pretty much obvious that a TDX guest can only run on CPUs where
the seam module has been initialized, but where does the requirement
come from that _ALL_ CPUs must be initialized and _ALL_ CPUs must be
able to run TDX guests?

I just went and read through the documentation again.

  "1. After loading the Intel TDX module, the host VMM should call the
      TDH.SYS.INIT function to globally initialize the module.

   2. The host VMM should then call the TDH.SYS.LP.INIT function on each
      logical processor. TDH.SYS.LP.INIT is intended to initialize the
      module within the scope of the Logical Processor (LP)."

This clearly tells me, that:

  1) TDX must be globally initialized (once)

  2) TDX must be initialized on each logical processor on which TDX
     root/non-root operation should be executed

But it does not define any requirement for doing this on all logical
processors and for preventing physical hotplug (Neither for CPUs nor for
memory).

Nothing in the TDX specs and docs mentions physical hotplug or a
requirement for invoking seamcall on the world.

Thanks,

        tglx