Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 May 2017 16:09:06 +0100
From:      Andrew Turner <andrew@fubar.geek.nz>
To:        mmel@freebsd.org
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:  <CAF5FFE5-4281-4854-AE84-AC60CBF50648@fubar.geek.nz>
In-Reply-To: <8fe20c26-3c0c-98ce-227b-740491253047@freebsd.org>
References:  <201705091105.v49B5WAp097952@repo.freebsd.org> <85745E3A-3260-43C7-B134-85BFED786D55@fubar.geek.nz> <8fe20c26-3c0c-98ce-227b-740491253047@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 9 May 2017, at 13:40, Michal Meloun <melounmichal@gmail.com> wrote:
>=20
>=20
>=20
> On 09.05.2017 13:34, Andrew Turner wrote:
>>> On 9 May 2017, at 12:05, Michal Meloun <mmel@FreeBSD.org> wrote:
>>>=20
>>> Author: mmel
>>> Date: Tue May  9 11:05:32 2017
>>> New Revision: 318021
>>> URL: https://svnweb.freebsd.org/changeset/base/318021
>>>=20
>>> Log:
>>> Introduce pmap_remap_vm_attr(),
>>> it allows to remap one VM memattr class to another.
>>>=20
>>> 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=E2=80=99t think it=E2=80=99s been answered if this is just for =
PCIe, or all devices.

>=20
>> 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=20
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF5FFE5-4281-4854-AE84-AC60CBF50648>