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
