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/[email protected]/ > >> >> 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- > [email protected]/ > >> >> 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
