On Oct 18, 2010, at 5:32 PM, Scott Wood wrote: > If mem= is used on the kernel command line to create reserved regions > for userspace to map using /dev/mem, let it be mapped cacheable as long > as it is within the memory region described in the device tree. > > Signed-off-by: Scott Wood <scottw...@freescale.com> > ---
Just a nit, but subject should be powerpc:.. not PPC: > This isn't just a performance issue, but it could also be a correctness > issue, if the reserved portion of RAM is mapped cacheable by e.g. a KVM > guest. This patch does not address cases where such regions could show up > as something other than a standard memory node -- such as shared regions > in an AMP configuration. Ideally there would be some means for a platform > to register cacheable regions, without having to completely replace the > entire phys_mem_access_prot function. > > This patch assumes that there is no region between memstart and memend that > must be non-cacheable. This is already the case with the "for now" > implementation of page_is_ram on 32-bit, but will this be a problem on > 64-bit? > > arch/powerpc/kernel/pci-common.c | 5 ++++- > arch/powerpc/kernel/prom.c | 3 +++ > arch/powerpc/mm/mem.c | 3 ++- > arch/powerpc/mm/mmu_decl.h | 1 + > 4 files changed, 10 insertions(+), 2 deletions(-) For some time I've been meaning for us to look at the address range tracking that x86 does so one can make sure we aren't mapping regions with different WIMG settings. However, never enough time for this. So I think this is reasonable for now. Hopefully Ben will comment on 64-bit side of the world. - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
