Date: Mon, 29 Feb 2016 17:18:16 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, Justin Hibbits <jrh29@alumni.cwru.edu>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RF_CACHEABLE flag Message-ID: <CAFHCsPVgJt9OJdUtKixGF1XSWtRiD1F8ZHCD5SRodQ77Wm%2B=Sw@mail.gmail.com> In-Reply-To: <CAJ-VmomUxb7nR7cyg58zHVrVP3MB2JLLebWJPf7kB0F7NDpu6A@mail.gmail.com> References: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com> <20160222121836.GH91220@kib.kiev.ua> <CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com> <20160224102754.GK91220@kib.kiev.ua> <CAJ-VmomUxb7nR7cyg58zHVrVP3MB2JLLebWJPf7kB0F7NDpu6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 24, 2016 at 6:14 PM, Adrian Chadd <adrian.chadd@gmail.com> wrote: > On 24 February 2016 at 02:27, Konstantin Belousov <kostikbel@gmail.com> wrote: >> On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: >>> This really isn't much different from bus_space_map() conceptually. >>> The work involved is pretty much the same, and if this route is deemed >>> the Wrong Way(TM), I'll go that route. >>> >>> Grepping through sys/, only x86 currently implements >>> pmap_change_attr(), and arm has the declaration but no definition that >>> I could see. Writing it wouldn't be difficult of course, there's just >>> not much compelling case for it right now. But, yes, either of these >>> alternatives are acceptable, and I had explored it. Seeing John >>> Baldwin's comment on the phab review, it looks like he wants to go a >>> different (parallel) direction. >> >> If this was not clear from my reply, I did not objected against RF_CACHEABLE, >> but was more to highlight weird needs of seemingly simple architecture, >> which are close to RF_CACHEABLE stuff. And, I think that architectures >> that care about caching modes, should do provide real pmap_change_attr() >> implementation. This might be important e.g. if drm is brought up on >> these platforms. > > heh, on ARM it's not "when". For MIPS it's also now "when". So I guess > yeah, we should implement it. > It's not so simple to change memory attributes on ARM. Some conditions must be met. So, a question is - in which circumstances pmap_change_attr() is used? It's defined like int pmap_change_attr(vm_offset_t va, vm_size_t size, int mode); (1) As memory attributes can be changed on a page basis only, the va and size are arranged according to that in i386 implementation. That's okay. (2) Can the memory be used by somebody else while the attributes are being changed? In other words, can the memory be unmapped temporary?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVgJt9OJdUtKixGF1XSWtRiD1F8ZHCD5SRodQ77Wm%2B=Sw>