Re: [PATCH v4 20/28] KVM: TDX: Assert that mmu_lock is held for write when removing S-EPT entries
From: Huang, Kai <hidden>
Date: 2025-10-30 23:03:18
Also in:
kvm, kvm-riscv, kvmarm, linux-arm-kernel, linux-coco, linux-mips, linux-riscv, lkml, loongarch
On Thu, 2025-10-30 at 13:09 -0700, Sean Christopherson wrote:
Unconditionally assert that mmu_lock is held for write when removing S-EPT entries, not just when removing S-EPT entries triggers certain conditions, e.g. needs to do TDH_MEM_TRACK or kick vCPUs out of the guest. Conditionally asserting implies that it's safe to hold mmu_lock for read when those paths aren't hit, which is simply not true, as KVM doesn't support removing S-EPT entries under read-lock. Only two paths lead to remove_external_spte(), and both paths asserts that
^ assert
mmu_lock is held for write (tdp_mmu_set_spte() via lockdep, and handle_removed_pt() via KVM_BUG_ON()). Deliberately leave lockdep assertions in the "no vCPUs" helpers to document that wait_for_sept_zap is guarded by holding mmu_lock for write, and keep the conditional assert in tdx_track() as well, but with a comment to help explain why holding mmu_lock for write matters (above and beyond why tdx_sept_remove_private_spte()'s requirements). Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Kai Huang <redacted>