Re: [PATCH v10 02/15] set_memory: add folio_{zap, restore}_direct_map helpers

David Hildenbrand (Arm)
2026-03-10T00:00:47Z

On 3/6/26 15:48, Nikita Kalyazin wrote:
>
>
> On 06/03/2026 14:17, David Hildenbrand (Arm) wrote:
>> On 3/6/26 13:48, Nikita Kalyazin wrote:
>>>
>>>
>>>
>>> Will update, thanks.
>>>
>>>
>>> Absolutely!
>>>
>>>
>>> Yes, on x86 we need an explicit flush.  Other architectures deal with it
>>> internally.
>>
>> So, we call a _noflush function and it performs a ... flush. What.
>
> Yeah, that's unfortunately the status quo as pointed by Aneesh [1]
>
> [1] https://lore.kernel.org/kvm/yq5ajz07czvz.fsf@kernel.org/
>
>>
>> Take a look at secretmem_fault(), where we do an unconditional
>> flush_tlb_kernel_range().
>>
>> Do we end up double-flushing in that case?
>
> Yes, looks like that.  I'll remove the explicit flush and rely on
> folio_zap_direct_map().
>
>>
>>> Do you propose a bespoke implementation for x86 and a
>>> "generic" one for others?
>>
>> We have to find a way to have a single set of functions for all archs
>> that support directmap removal.
>
> I believe Dave meant to address that with folio_{zap,restore}
> _direct_map() [2].
>
> [2] https://lore.kernel.org/kvm/9409531b-589b-4a54-
> b122-06a3cf0846f3@intel.com/
>
>>
>> One option might be to have some indication from the architecture that
>> no flush_tlb_kernel_range() is required.
>>
>> Could be a config option or some simple helper function.
>
> I'd be inclined to know what arch maintainers think because I don't have
> a strong opinion on that.

You could also just perform a double flush, and let people that
implemented a _noflush() to perform a flush optimize that later.

I mean, that's what secretmem did :)

--
Cheers,

David