On Mon, Jul 15, 2019 at 8:41 PM Thomas Gleixner <t...@linutronix.de> wrote: > > On Mon, 15 Jul 2019, Andi Kleen wrote: > > Uros Bizjak <ubiz...@gmail.com> writes: > > > > > Recent patch [1] disabled a self-snoop feature on a list of processor > > > models with a known errata, so we are confident that the feature > > > should work on remaining models also for other purposes than to speed > > > up MTRR programming. > > > > MTRR is very different than TLBs. > > > > >From my understanding not flushing with PAT is only safe everywhere when > > the memory is only used for coherent devices (like the Internal GPU on > > Intel CPUs). We don't have any infrastructure to track or enforce > > this unfortunately. > > Right, we don't know where the PAT invocation comes from and whether they > are safe to omit flushing the cache. The module load code would be one > obvious candidate. > > But unless there is some really worthwhile speedup, e.g. for boot, then > adding some flag to let CPA know about the safe 'no flush' operation might > be not worth it.
For the reference, FreeBSD implements this approach, later changed to use pmap_invalidate_cache_range ifunc (that calls pmap_invalidate_cache_range_selfsnoop for targets with self-snoop capability) and pmap_force_invalidate_cache_range [1]. The full cross-referenced source is at [2]. [1] https://reviews.freebsd.org/D16736 [2] http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c Uros.
