Messages in this thread | | | Date | Wed, 23 Nov 2022 17:37:33 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCH v7 06/20] x86/virt/tdx: Shut down TDX module in case of error |
| |
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.
| |