On Thu, 2016-03-10 at 22:47 -0800, Andy Lutomirski wrote: > On Mon, Mar 7, 2016 at 9:03 AM, Toshi Kani <toshi.kani@xxxxxxx> wrote: > > Let me try to summarize... > > > > The original issue Luis brought up was that drivers written to work > > with MTRR may create a single ioremap range covering multiple cache > > attributes since MTRR can overwrite cache attribute of a certain > > range. Converting such drivers with PAT-based ioremap interfaces, i.e. > > ioremap_wc() and ioremap_nocache(), requires a separate ioremap map for > > each cache attribute, which can be challenging as it may result in > > overlapping ioremap ranges (in his term) with different cache > > attributes. > > > > So, Luis asked about 'sematics of overlapping ioremap()' calls. Hence, > > I responded that aliasing mapping itself is supported, but alias with > > different cache attribute is not. We have checks in place to detect > > such condition. Overlapping ioremap calls with a different cache > > attribute either fails or gets redirected to the existing cache > > attribute on x86. > > A little off-topic, but someone reminded me recently: most recent CPUs > have self-snoop. It's poorly documented, but on self-snooping CPUs, I > think that a lot of the aliasing issues go away. We may be able to > optimize the code quite a bit on these CPUs. Interesting. I wonder how much we can rely on this feature. Yes, by looking at Intel SDM, it is indeed poorly documented. :-( > I also wonder whether we can drop a bunch of the memtype tracking. > After all, if we have aliases of different types on a self-snooping > CPU and /dev/mem is locked down hard enough, we could maybe get away > with letting self-snoop handle all the conflicts. > > (We could also make /dev/mem always do UC if it would help.) It'd be interesting to know how it performs on an aliased map when it works correctly... Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
