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. * Physical Address Metadata Table, a large physically contiguous data structure, the rough equivalent of 'struct page' for the TDX module
