Re: [PATCH 07/17] KVM: x86/tdp_mmu: Centralize updates to present external PTEs

Yan Zhao
2026-04-08T02:03:12Z

On Wed, Apr 08, 2026 at 01:21:26AM +0800, Edgecombe, Rick P wrote:
> On Tue, 2026-04-07 at 16:34 +0800, Yan Zhao wrote:
> > (a1)(a2) May hit KVM_BUG_ON() in handle_changed_spte() if
> >          tdx_sept_set_private_spte() fails due to contentions. e.g.,
> >          tdh_mem_sept_add(), tdx_mem_page_aug(), or tdx_mem_page_add() may
> >          contend with tdh_vp_enter() due to zero-step mitigation or may
> >          potentially contend with TDCALLs.
> > (b) Promotion case. Currently unreachable in mirror root.
> >     Need more complex changes in TDP MMU if we want to support it in the future.
> > (c) Will not hit KVM_BUG_ON() in TDP MMU, but will trigger warnings in
> >     tdx_sept_remove_private_spte() due to lockdep_assert_held_write() or
> >     TDX_BUG_ON() caused by concurrent BLOCK, TRACK, REMOVE.
> > (d) May hit the KVM_BUG_ON() in handle_changed_spte() due to failure to remove
> >     child S-EPT entries and will trigger warnings in
> >     tdx_sept_remove_private_spte() due to lockdep_assert_held_write() or
> >     TDX_BUG_ON() caused by concurrent BLOCK, TRACK, REMOVE.
> >     May also trigger TDX_BUG_ON() in tdx_sept_reclaim_private_spt().
>
> Ok! I wonder if we could (not for this series) encode this information into some
> centralized helper on the TDX side. It's nice to see it all together. Not sure
> on the idea.
Maybe some code comments to tdx_sept_set_private_spte() and
tdx_sept_free_private_spt()?