On Fri, Apr 12, 2024, Kai Huang wrote: > On 12/04/2024 2:03 am, Sean Christopherson wrote: > > On Thu, Apr 11, 2024, Kai Huang wrote: > > > I can certainly follow up with this and generate a reviewable patchset if I > > > can confirm with you that this is what you want? > > > > Yes, I think it's the right direction. I still have minor concerns about VMX > > being enabled while kvm.ko is loaded, which means that VMXON will _always_ be > > enabled if KVM is built-in. But after seeing the complexity that is needed to > > safely initialize TDX, and after seeing just how much complexity KVM already > > has because it enables VMX on-demand (I hadn't actually tried removing that code > > before), I think the cost of that complexity far outweighs the risk of "always" > > being post-VMXON. > > Does always leaving VMXON have any actual damage, given we have emergency > virtualization shutdown? Being post-VMXON increases the risk of kexec() into the kdump kernel failing. The tradeoffs that we're trying to balance are: is the risk of kexec() failing due to the complexity of the emergency VMX code higher than the risk of us breaking things in general due to taking on a ton of complexity to juggle VMXON for TDX? After seeing the latest round of TDX code, my opinion is that being post-VMXON is less risky overall, in no small part because we need that to work anyways for hosts that are actively running VMs. > > Within reason, I recommend getting feedback from others before you spend _too_ > > much time on this. It's entirely possible I'm missing/forgetting some other angle. > > Sure. Could you suggest who should we try to get feedback from? > > Perhaps you can just help to Cc them? I didn't have anyone in particular in mind, I just really want *someone* to weigh in as a sanity check.
