Re: [PATCH] KVM: x86: use again the flush argument of __link_shadow_page()

[Sean Christopherson]

On Tue, May 05, 2026, Paolo Bonzini wrote:
> On Mon, May 4, 2026 at 8:36 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > An amendment to that: I thought this was just switching back to the more targeted
> > range-based flushed, I didn't realize you applied the version that hardcoded the
> > @flush param to kvm_mmu_remote_flush_or_zap() with "true".
> 
> Yes, I was hoping to simplify stable backports a bit.  Here is my
> version of your comment (yes, I did try adding batched zapping to
> shadow_mmu_split_huge_page() and failed):
> 
> /*
>  * Note: while normally KVM uses a "bool flush" return value to let
>  * the caller batch flushes, __link_shadow_page() flushes immediately
>  * immediately before populating the parent PTE with the new shadow page.
>  * The typical callers, direct_map() and FNAME(fetch)(), are not going
>  * to zap more than one large SPTE anyway.
>  *
>  * The only exception, where @flush can be false, is when a large SPTE

Can we use "huge" instead of "large"?  KVM has lots of references to both, but
the kernel generally uses "huge", so I've been trying to opportunistically switch
to "huge".

>  * is replaced with a large SPTE with a fully populated page table,

I think you want "a shadow page SPTE" here?

>  * which can happen from shadow_mmu_split_huge_page().  In this case,
>  * no memory is unmapped across the change to the page tables and no
>  * immediate flush is needed for correctness.
>  *
>  * Even in that case, calls to kvm_mmu_commit_zap_page() are not
>  * batched.  Doing so would require adding an invalid_list argument
>  * all the way down to __walk_slot_rmaps().
>  */
> 
> What do you think?

Other than the nit and the goof, LGTM.