On Tue, Dec 17, 2024, Rick P Edgecombe wrote: > On Thu, 2024-11-21 at 19:51 +0800, Yan Zhao wrote: > > This SEPT SEAMCALL retry proposal aims to remove patch > > "[HACK] KVM: TDX: Retry seamcall when TDX_OPERAND_BUSY with operand SEPT" > > [1] at the tail of v2 series "TDX MMU Part 2". > > We discussed this on the PUCK call. A couple alternatives were considered: > - Avoiding 0-step. To handle signals kicking to userspace we could try to add > code to generate synthetic EPT violations if KVM thinks the 0-step mitigation > might be active (i.e. the fault was not resolved). The consensus was that this > would be continuing battle and possibly impossible due normal guest behavior > triggering the mitigation. Specifically, the TDX Module takes its write-lock if the guest takes EPT violations exits on the same RIP 6 times, i.e. detects forward progress based purely on the RIP at entry vs. exit. So a guest that is touching memory in a loop could trigger zero-step checking even if KVM promptly fixes every EPT violation. > - Pre-faulting all S-EPT, such that contention with AUG won't happen. The > discussion was that this would only be a temporary solution as the MMU > operations get more complicated (huge pages, etc). Also there is also > private/shared conversions and memory hotplug already. > > So we will proceed with this kick+lock+retry solution. The reasoning is to > optimize for the normal non-contention path, without having an overly > complicated solution for KVM. > > In all the branch commotion recently, these patches fell out of our dev branch. > So we just recently integrated then into a 6.13 kvm-coco-queue based branch. We > need to perform some regression tests based on 6.13 TDP MMU changes. Assuming no > issues, we can post the 6.13 rebase to included in kvm-coco-queue with > instructions on which patches to remove from kvm-coco-queue (i.e. the 16 > retries). > > > We also briefly touched on the TDX module behavior where guest operations can > lock NP PTEs. The kick solution doesn't require changing this functionally, but > it should still be done to help with debugging issues related to KVM's > contention solution. And so that KVM developers don't have to deal with customer escalations due to performance issues caused by known flaws in the TDX module. > > Thanks all for the discussion!
