[PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Jan 28 08:05:32 EST 2011
On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > > using LDREX/STREX breaks COW.
> > > >
> > > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > > on ARMv7, and if SWP emulation is built, disable it at that point.
> > >
> > > We can't disable the SWP instruction as long as domains are enabled (COW
> > > not working for in-kernel STREX).
> > >
> > > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > > independent of the domains setting and have early_trap_init() use
> > > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > > ARM11MPCore as well because of the way we interpret CPUID).
> >
> > What about a kernel covering ARMv6 too? Writing to an aliased mapping
> > of the vectors page (as required for TLS emulation) will require
> > additional cache maintainence on every context switch.
>
> With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> v6 is compiled in? If that's the case, we may have a problem - I talked
> to the toolchain guys and it looks like code optimised for ARMv7 reads
> the TLS register directly without going through the kuser helper.
That's not a problem, because you wouldn't run ARMv7 optimized userspace
on an ARMv6 CPU. That's not what this whole exercise is about.
More information about the linux-arm-kernel
mailing list