> > Since I think doing VMXON when bringing up CPU unconditionally is a > > dramatic move at this stage, I was actually thinking we don't do VMXON > > in CPUHP callback, but only do prepare things like sanity check and > > VMXON region setup etc. If anything fails, we refuse to online CPU, > > or mark CPU as VMX not supported, whatever. > > the whole point is to always vmxon -- and simplify all the complexity from doing > this dynamic. > So yes "dramatic" maybe but needed -- especially as things like TDX and TDX > connect need vmxon to be enabled outside of KVM context. > > > > > > The core kernel then provides two APIs to do VMXON/VMXOFF > > respectively, and KVM can use them. The APIs needs to handle > > concurrent requests from multiple users, though. VMCLEAR could still > > be in KVM since this is kinda KVM's internal on how to manage vCPUs. > > > > Does this make sense? > > not to me -- the whole point is to not having this dynamic thing Sure. Fine to me to just always on.
