On Wed, Nov 23, 2022, Dave Hansen wrote: > On 11/23/22 08:20, Sean Christopherson wrote: > >>> 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. > > There's no way we can guarantee _that_. For one, the PAMT* allocations > can always fail. I guess we could ask sysadmins to fire up a guest to > "prime" things, but that seems a little silly. Maybe that would work as > the initial implementation that we merge, but I suspect our users will > demand more determinism, maybe a boot or module parameter. Oh, you mean all of TDX initialization? I thought "initialization" here mean just doing tdx_enable(). Yeah, that's not going to be a viable option. Aside from lacking determinisim, it would be all too easy to end up on a system with fragmented memory that can't allocate the PAMTs post-boot.
