On 12/4/23 18:04, Sean Christopherson wrote: > Joking aside, why shove TDX module ownership into KVM? It honestly sounds like > a terrible fit, even without the whole TDX-IO mess. KVM state is largely ephemeral, > in the sense that loading and unloading kvm.ko doesn't allocate/free much memory > or do all that much initialization or teardown. Yeah, you have a good point there. We really do need some core code to manage VMXON/OFF now that there is increased interest outside of _purely_ running VMs. For the purposes of _this_ patch, I think I'm happy to leave open the possibility that SEAMCALL can simply fail due to VMXOFF. For now, it means that we can't attribute #MC's to the PAMT unless a VM is running but that seems like a reasonable compromise for the moment. Once TDX gains the ability to "pin" VMXON, the added precision here will be appreciated.
