On Wed, 10 Aug 2022, Dan Williams wrote:
I expect the interface would not be in the "flush_cache_" namespace since those functions are explicitly for virtually tagged caches that need maintenance on TLB operations that change the VA to PA association. In this case the cache needs maintenance because the data at the PA changes. That also means that putting it in the "nvdimm_" namespace is also wrong because there are provisions in the CXL spec where volatile memory ranges can also change contents at a given PA, for example caches might need to be invalidated if software resets the device, but not the platform. Something like: region_cache_flush(resource_size_t base, resource_size_t n, bool nowait) ...where internally that function can decide if it can rely on an instruction like wbinvd, use set / way based flushing (if set / way maintenance can be made to work which sounds like no for arm64), or map into VA space and loop. If it needs to fall back to that VA-based loop it might be the case that the caller would want to just fail the security op rather than suffer the loop latency.
Yep, I was actually prototyping something similar, but want to still reuse cacheflush.h machinery and just introduce cache_flush_region() or whatever name, which returns any error. So all the logic would just be per-arch, where x86 will do the wbinv and return 0, and arm64 can just do -EINVAL until VA-based is no longer the only way. Thanks, Davidlohr
