Date: Tue, 9 May 2017 14:40:29 +0200 From: Michal Meloun <melounmichal@gmail.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r318021 - in head/sys/arm: arm include Message-ID: <8fe20c26-3c0c-98ce-227b-740491253047@freebsd.org> In-Reply-To: <85745E3A-3260-43C7-B134-85BFED786D55@fubar.geek.nz> References: <201705091105.v49B5WAp097952@repo.freebsd.org> <85745E3A-3260-43C7-B134-85BFED786D55@fubar.geek.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09.05.2017 13:34, Andrew Turner wrote: >> On 9 May 2017, at 12:05, Michal Meloun <mmel@FreeBSD.org> 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. */ > 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. Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8fe20c26-3c0c-98ce-227b-740491253047>