Sean Christopherson wrote: [..] > > Sounds reasonable to me. > > > > Not clear on how it impacts tdx_tsm implementation. The lifetime of this > > tdx_tsm device can still be bound by tdx_enable() / tdx_cleanup(). The > > refactor removes the need for the autoprobe hack below. It may also > > preclude async vmxoff cases by pinning? Or does pinning still not solve > > the reasons for bouncing vmx on suspend/shutdown? > > What exactly is the concern with suspend/shutdown? I was confused by Yilun's diagram that suggested vmxoff scenarios while kvm_intel is still loaded. > Suspend should be a non-issue, as userspace tasks need to be frozen before the > kernel fires off the suspend notifiers. Ditto for a normal shutdown. Yes, tdx_tsm can stay registered over those events. > Forced shutdown will be asynchronous with respect to running vCPUs, but all bets > are off on a forced shutdown. Ditto for disabling VMX via NMI shootdown on a > crash. Ok, to repeat back the implications: async vmxoff is not something that needs to gracefully shutdown the tdx_tsm device or system-wide TDX services. Those are already going to error out in the force shutdown case. tdx_tsm is a module for system-wide tdx_tsm services. Its lifetime starts at tdx_enable() and ends at tdx_cleanup(). Until a refactor completes tdx_enable() is called from the kvm_intel init path. Post refactor, tdx_enable() is in a system-wide TDX services module that depends on a shared module, not kvm_intel, to manage vmxon. kvm_intel is a peer client of this shared vmx module. While the TDX TEE I/O (device security) RFC is in flight the implementation will go through a phase of userspace needing to demand-load kvm_intel. The final implementation for mainline will have broken tdx_tsm's dependency on kvm_intel.
