> On 9 May 2017, at 13:40, Michal Meloun <[email protected]> wrote: > > > > On 09.05.2017 13:34, Andrew Turner wrote: >>> On 9 May 2017, at 12:05, Michal Meloun <[email protected]> wrote: >>> >>> Author: mmel >>> Date: Tue May 9 11:05:32 2017 >>> New Revision: 318021 >>> URL: https://svnweb.freebsd.org/changeset/base/318021 >>> >>> Log: >>> Introduce pmap_remap_vm_attr(), >>> it allows to remap one VM memattr class to another. >>> >>> This function is intent to be used as workaround for various SoC bugs, >>> mainly access ordering/sequencing related bugs in crossbar fabric. >> This seems quite heavy handed to change the attribute for all memory of a >> given type. > Yes, exactly. See comment in D10218 - > /* > * Workaround for Marvell Armada38X family HW issue > * between Cortex-A9 CPUs and on-chip devices that may > * cause hang on heavy load. > * To avoid that, map all registers including PCIe IO > * as strongly ordered instead of device memory. > */
I don’t think it’s been answered if this is just for PCIe, or all devices. > >> Other architectures have pmap_change_attr to change the attribute on a >> specific range of memory. > Right. Problem is that I don't known any method how we can change > memory attribute for live memory in SMP system, > without hitting undefined behavior. I would expect drivers to change the attributes early, before they access the memory. We could also use smp_rendezvous to ensure nothing else is running, this will have a performance code, however I would not expect pmap_change_attr to be used in the fast path. Andrew _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
