Re: [PATCH v7 05/12] KVM: guest_memfd: Add flag to remove from direct map

[Nikita Kalyazin]

On 03/11/2025 07:57, Aneesh Kumar K.V wrote:
> "Roy, Patrick" <roypat@xxxxxxxxxxxx> writes:
>
> ....
>
> > +static int kvm_gmem_folio_zap_direct_map(struct folio *folio)
> > +{
> > +     if (kvm_gmem_folio_no_direct_map(folio))
> > +             return 0;
> > +
> > +     int r = set_direct_map_valid_noflush(folio_page(folio, 0), folio_nr_pages(folio),
> > +                                      false);
> > +
> > +     if (!r) {
> > +             unsigned long addr = (unsigned long) folio_address(folio);
> > +             folio->private = (void *) ((u64) folio->private & KVM_GMEM_FOLIO_NO_DIRECT_MAP);
> > +             flush_tlb_kernel_range(addr, addr + folio_size(folio));
> > +     }
> > +
> > +     return r;
> > +}
>
> These 'noflush' functions are actually doing flush_tlb_kernel
>
> [-]  ∘ flush_tlb_kernel_range
>   |-[-]  ← __change_memory_common
>   |  `-[-]  ← set_memory_valid
>   |     `-   ← set_direct_map_valid_noflush

Hi Aneesh,

Thanks for pointing at that.  I ran internal tests and it appears that 
the second flush_tlb_kernel_range() call does add a latency similar to 
the one coming from the first call, even though it intuitively should be 
a no-op.  I have to admit that I am not aware of a safe way to avoid the 
second flushing on ARM while keeping the guest_memfd code arch-agnostic. 
 Perhaps I should seek Will's counsel for it.  Nevertheless, I don't 
think there is a concern from the functional point of view.

Nikita

> -aneesh