On Wed, Nov 23, 2022, Huang, Kai wrote: > On Tue, 2022-11-22 at 17:04 -0800, Dave Hansen wrote: > > On 11/22/22 16:58, Huang, Kai wrote: > > > On Tue, 2022-11-22 at 11:24 -0800, Dave Hansen wrote: > > > > > I was expecting TDX to not get initialized until the first TDX using KVM > > > > > instance is created. Am I wrong? > > > > I went looking for it in this series to prove you wrong. I failed. 😄 > > > > > > > > tdx_enable() is buried in here somewhere: > > > > > > > > > https://lore.kernel.org/lkml/CAAhR5DFrwP+5K8MOxz5YK7jYShhaK4A+2h1Pi31U_9+Z+cz-0A@xxxxxxxxxxxxxx/T/ > > > > I don't have the patience to dig it out today, so I guess we'll have Kai > > > > tell us. > > > It will be done when KVM module is loaded, but not when the first TDX guest is > > > created. > > > > Why is it done that way? > > > > Can it be changed to delay TDX initialization until the first TDX guest > > needs to run? > > > > Sean suggested. > > Hi Sean, could you commenet? Waiting until the first TDX guest is created would result in false advertising, as KVM wouldn't know whether or not TDX is actually supported until that first VM is created. If we can guarantee that TDH.SYS.INIT will fail if and only if there is a kernel bug, then I would be ok deferring the "enabling" until the first VM is created.
