Re: [PATCH v11 018/113] KVM: TDX: create/destroy VM structure

From: Sean Christopherson
Date: Tue Jan 17 2023 - 18:16:33 EST


On Tue, Jan 17, 2023, Sean Christopherson wrote:
> On Tue, Jan 17, 2023, Zhi Wang wrote:
> > 2) As TDX module doesn't provide contention-and-wait, I guess the following
> > approach might have been discussed when designing this "retry".
> >
> > KERNEL TDX MODULE
> >
> > SEAMCALL A -> PATH A: Taking locks
> >
> > SEAMCALL B -> PATH B: Contention on a lock
> >
> > <- Return "operand busy"
> >
> > SEAMCALL B -|
> > | <- Wait on a kernel waitqueue
> > SEAMCALL B <-|
> >
> > SEAMCALL A <- PATH A: Return
> >
> > SEAMCALL A -|
> > | <- Wake up the waitqueue
> > SEMACALL A <-|
> >
> > SEAMCALL B -> PATH B: Taking the locks
> > ...
> >
> > Why not this scheme wasn't chosen?
>
> AFAIK, I don't think a waitqueue approach as ever been discussed publicly. Intel
> may have considered the idea internally, but I don't recall anything being proposed
> publically (though it's entirely possible I just missed the discussion).
>
> Anways, I don't think a waitqueue would be a good fit, at least not for S-EPT
> management, which AFAICT is the only scenario where KVM does the arbitrary "retry
> X times and hope things work". If the contention occurs due to the TDX Module
> taking an S-EPT lock in VM-Enter, then KVM won't get a chance to do the "Wake up
> the waitqueue" action until the next VM-Exit, which IIUC is well after the TDX
> Module drops the S-EPT lock. In other words, immediately retrying and then punting
> the problem further up the stack in KVM does seem to be the least awful "solution"
> if there's contention.

Oh, the other important piece I forgot to mention is that dropping mmu_lock deep
in KVM's MMU in order to wait isn't always an option. Most flows would play nice
with dropping mmu_lock and sleeping, but some paths, e.g. from the mmu_notifier,
(conditionally) disallow sleeping.