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

Nikita Kalyazin
2025-12-05T17:23:31Z

On 03/11/2025 07:57, Aneesh Kumar K.V wrote:
> "Roy, Patrick" <roypat@amazon.co.uk> 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