On Thu, 01 Dec 2022, Dan Williams wrote:
A "DPA invalidation event" is any scenario where the contents of a DPA
(Device Physical Address) is modified in a way that is incoherent with
CPU caches, or if the HPA (Host Physical Address) to DPA association
changes due to a remapping event.
PMEM security events like Unlock and Passphrase Secure Erase already
manage caches through LIBNVDIMM,
Just to be clear, is this is why you get rid of the explicit flushing
for the respective commands in security.c?
so that leaves HPA to DPA remap events
that need cache management by the CXL core. Those only happen when the
boot time CXL configuration has changed. That event occurs when
userspace attaches an endpoint decoder to a region configuration, and
that region is subsequently activated.
The implications of not invalidating caches between remap events is that
reads from the region at different points in time may return different
results due to stale cached data from the previous HPA to DPA mapping.
Without a guarantee that the region contents after cxl_region_probe()
are written before being read (a layering-violation assumption that
cxl_region_probe() can not make) the CXL subsystem needs to ensure that
reads that precede writes see consistent results.
Hmm where does this leave us remaping under arm64 which is doesn't have
ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION?
Back when we were discussing this it was all related to the security stuff,
which under arm it could just be easily discarded as not available feature.
Thanks,
Davidlohr
