Re: [RFC PATCH v2 12/23] KVM: x86/mmu: Introduce kvm_split_cross_boundary_leafs()

[Yan Zhao]

Hi Kai and all,

Let me summarize my points clearly in advance:
(I guess I failed to do it explicitly in my previous mails [1][2]).

- I agree with Kai's suggestion to return a "bool *split" to callers of
  kvm_split_cross_boundary_leafs(). The callers can choose to do TLB flush or
  not, since we don't want them to do TLB flush unconditionally. (see the "Note"
  below).

- I think it's OK to skip TLB flush before tdp_mmu_iter_cond_resched() releases
  the mmu_lock in tdp_mmu_split_huge_pages_root(), as there's no known use case
  impacted up to now, according to the analysis in [1].

- Invoke kvm_flush_remote_tlbs() for tdp_mmu_split_huge_pages_root() in this
  series is for
  a) code completeness.
     kvm_split_cross_boundary_leafs() does not force that the root must be a
     mirror root.

     TDX alone doesn't require invoking kvm_flush_remote_tlbs() as it's done
     implicitly in tdx_sept_split_private_spt(). TDX share memory also does not
     invoke kvm_split_cross_boundary_leafs().

  b) code consistency.
     kvm_unmap_gfn_range() also returns flush for callers to invoke
     kvm_flush_remote_tlbs(), even when the range is of KVM_FILTER_PRIVATE
     alone.

I'll update the patch with proper comments to explain the above points if you
are agreed.

Thanks
Yan

Note:
Currently there are 3 callers of kvm_split_cross_boundary_leafs():
1) tdx_check_accept_level(), which actually has no need to invoke
   kvm_flush_remote_tlbs() since it splits mirror root only.

2) kvm_arch_pre_set_memory_attributes(), which can combine the flush together
   with the TLB flush due to kvm_unmap_gfn_range().

3) kvm_gmem_split_private(), which is invoked by gmem punch_hole and gmem
   conversion from private to shared. The caller can choose to do TLB flush
   separately or together with kvm_gmem_zap() later.


[1] https://lore.kernel.org/all/aRbHtnMcoqM1gmL9@xxxxxxxxxxxxxxxxxxxxxxxxx
[2] https://lore.kernel.org/all/aRwSkc10XQqY8RfE@xxxxxxxxxxxxxxxxxxxxxxxxx

On Tue, Nov 18, 2025 at 06:49:31PM +0800, Huang, Kai wrote:
> > >
Will reply the rest of your mail seperately later.