[PATCH v9 07/13] KVM: guest_memfd: Add flag to remove from direct map

Nikita Kalyazin kalyazin at amazon.com
Thu Jan 22 12:40:46 PST 2026



On 22/01/2026 20:30, Ackerley Tng wrote:
> Nikita Kalyazin <kalyazin at amazon.com> writes:
> 
>>
>> [...snip...]
>>
>>>>>> @@ -533,6 +580,8 @@ static void kvm_gmem_free_folio(struct folio *folio)
>>>>>>          kvm_pfn_t pfn = page_to_pfn(page);
>>>>>>          int order = folio_order(folio);
>>>>>>
>>>>>> +     kvm_gmem_folio_restore_direct_map(folio);
>>>>>> +
>>>>>
>>>>> I can't decide if the kvm_gmem_folio_no_direct_map(folio) should be in
>>>>> the caller or within kvm_gmem_folio_restore_direct_map(), since this
>>>>> time it's a folio-specific property being checked.
>>>>
>>>> I'm tempted to keep it similar to the kvm_gmem_folio_zap_direct_map()
>>>> case.  How does the fact it's a folio-speicific property change your
>>>> reasoning?
>>>>
>>>
>>> This is good too:
>>>
>>>     if (kvm_gmem_folio_no_direct_map(folio))
>>>             kvm_gmem_folio_restore_direct_map(folio)
>>
>> It turns out we can't do that because folio->mapping is gone by the time
>> filemap_free_folio() is called so we can't inspect the flags.  Are you
>> ok with only having this check when zapping (but not when restoring)?
>> Do you think we should add a comment saying it's conditional here?
>>
> 
> I thought kvm_gmem_folio_no_direct_map() only reads folio->private,
> which I think should still be there at the point of
> filemap_free_folio().

Oh, I misread your last reply.  What you're proposing would work indeed.

> 
>>>
>>> [...snip...]
>>>




More information about the linux-riscv mailing list