[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aR0Byu3bd3URxzhu@google.com>
Date: Tue, 18 Nov 2025 15:31:22 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Rick Edgecombe <rick.p.edgecombe@...el.com>
Cc: ackerleytng@...gle.com, anup@...infault.org, aou@...s.berkeley.edu,
binbin.wu@...ux.intel.com, borntraeger@...ux.ibm.com, chenhuacai@...nel.org,
frankja@...ux.ibm.com, imbrenda@...ux.ibm.com, ira.weiny@...el.com,
kai.huang@...el.com, kas@...nel.org, kvm-riscv@...ts.infradead.org,
kvm@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-coco@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
linux-riscv@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
loongarch@...ts.linux.dev, maddy@...ux.ibm.com, maobibo@...ngson.cn,
maz@...nel.org, michael.roth@....com, oliver.upton@...ux.dev,
palmer@...belt.com, pbonzini@...hat.com, pjw@...nel.org,
vannapurve@...gle.com, x86@...nel.org, yan.y.zhao@...el.com,
zhaotianrui@...ngson.cn
Subject: Re: [PATCH] KVM: TDX: Take MMU lock around tdh_vp_init()
On Mon, Oct 27, 2025, Rick Edgecombe wrote:
> Take MMU lock around tdh_vp_init() in KVM_TDX_INIT_VCPU to prevent
> meeting contention during retries in some no-fail MMU paths.
>
> The TDX module takes various try-locks internally, which can cause
> SEAMCALLs to return an error code when contention is met. Dealing with
> an error in some of the MMU paths that make SEAMCALLs is not straight
> forward, so KVM takes steps to ensure that these will meet no contention
> during a single BUSY error retry. The whole scheme relies on KVM to take
> appropriate steps to avoid making any SEAMCALLs that could contend while
> the retry is happening.
>
> Unfortunately, there is a case where contention could be met if userspace
> does something unusual. Specifically, hole punching a gmem fd while
> initializing the TD vCPU. The impact would be triggering a KVM_BUG_ON().
>
> The resource being contended is called the "TDR resource" in TDX docs
> parlance. The tdh_vp_init() can take this resource as exclusive if the
> 'version' passed is 1, which happens to be version the kernel passes. The
> various MMU operations (tdh_mem_range_block(), tdh_mem_track() and
> tdh_mem_page_remove()) take it as shared.
>
> There isn't a KVM lock that maps conceptually and in a lock order friendly
> way to the TDR lock. So to minimize infrastructure, just take MMU lock
> around tdh_vp_init(). This makes the operations we care about mutually
> exclusive. Since the other operations are under a write mmu_lock, the code
> could just take the lock for read, however this is weirdly inverted from
> the actual underlying resource being contended. Since this is covering an
> edge case that shouldn't be hit in normal usage, be a little less weird
> and take the mmu_lock for write around the call.
>
> Fixes: 02ab57707bdb ("KVM: TDX: Implement hooks to propagate changes of TDP MMU mirror page table")
> Reported-by: Yan Zhao <yan.y.zhao@...el.com>
> Suggested-by: Yan Zhao <yan.y.zhao@...el.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
> ---
> Hi,
>
> It was indeed awkward, as Sean must have sniffed. But seems ok enough to
> close the issue.
>
> Yan, can you give it a look?
>
> Posted here, but applies on top of this series.
In the future, please don't post in-reply-to, as it mucks up my b4 workflow.
Applied to kvm-x86 tdx, with a more verbose comment as suggested by Binbin.
[1/1] KVM: TDX: Take MMU lock around tdh_vp_init()
https://github.com/kvm-x86/linux/commit/9a89894f30d5
Powered by blists - more mailing lists