summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/kdoc_output.py
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2025-10-30 13:09:43 -0700
committerSean Christopherson <seanjc@google.com>2025-11-05 11:07:04 -0800
commit2ff14116982c663066f3cdb4e2af5dfa7a812caa (patch)
treecbe5740a9fe4e5d5f3eb2ec46d761a41ec60e5e9 /tools/lib/python/kdoc/kdoc_output.py
parent55560b6be5bc39384917ff456d1c9ba0a3790277 (diff)
KVM: TDX: Assert that mmu_lock is held for write when removing S-EPT entries
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 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). Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Tested-by: Yan Zhao <yan.y.zhao@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20251030200951.3402865-21-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/lib/python/kdoc/kdoc_output.py')
0 files changed, 0 insertions, 0 deletions