On Fri, Mar 11, 2016 at 2:36 PM, Toshi Kani <toshi.kani@xxxxxxx> wrote: > 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. :-( Any Intel people want to give us a hint? --Andy -- 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
