Re: [RFC PATCH 07/20] x86/virt/tdx: Expose SEAMLDR information via sysfs

[<dan.j.williams@intel.com>]

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.