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. 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.) --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
