On 08/24/2010 03:43 PM, Mike Frysinger wrote:
Apparently the ARM MPU's are not nearly as capable as the blackfin MPU.
The ARM MPU deals with whole regions, and typically only up to 8 memory
regions can be controlled by the MPU at any one time, each region having
one protection setting (r/w/x for kernel mode, r/w/x for user mode). Not
nearly as fine grained as per-page.
i dont quite understand what you mean by "whole region". if you define a
"region" as 4KiB, dont you get the granularity expected ? could you describe
the flexibility/restrictions of this a little more (i'm not an ARM core guy) ?
the Blackfin MPU has separate insn/data TLBs, and each TLB has 16 entries
(PTEs i believe is the common naming). each PTE has supervisor rwx and
usermode rwx permissions. further, each PTE has a size field which may be
1KiB, 4KiB, 1MiB, or 4MiB.
ok, sounds like the blackfin MPU has all the features of a true MMU but
without the v-->p address translation.
The ARM MPU, using MMU language, has an 8-entry TLB (some ARM MPUs have
separate insn/data TLBs, others don't). But here's the kicker, the
entire address space can only be described by 8 PTE's (aka MPU regions),
total! So actually there is no need for a page table in main memory at
all, since the TLB already has enough entries to cover the entire
address space.
i guess we cheat a little and we lock a PTE for the kernel itself so that
it'll always be covered so we can process PTE misses without triggering a miss
(nested exceptions). i'm not entirely familiar with the exact gory details of
other arches, so i cant say how unique we are in this regard.
The ARM MPU can do something similar. MPU regions can overlap, and a
simple priority scheme is used to decide which region's permissions
apply to a memory access that overlaps (higher numbered regions have
higher priority). So on ARM we can "lock" a PTE/region, by defining
region 0 to cover the entire address space, and give kernel read/write
access, user no access. And region 0 is never overwritten or disabled.
So if an access is made to an address not described by any other region,
region 0 permissions are applied to the access (and a protection fault
is generated if the access was made in user mode).
Note that, with region 0 locked, that only leaves 7 PTEs/regions that
can be swapped in and out for user processes. So with the ARM MPU, we
can't create a region for every mmap(), we would run out of available
entries. So we have to use a trade-off, only create an MPU region for
XIP file mappings (text). All other mappings (non-XIP file mappings and
anonymous mappings) allocate from a common user memory pool (which is
another patch I plan to submit).
So another locked region is used (region 1) that covers this user memory
pool. User mode has read/write access of course, as well as kernel. And
so we actually now only have 6 regions that user processes can play with.
What this trade-off means is that we have process-to-kernel protection,
but not process-to-process protection.
So ARM could use something higher-level than protect_page(), something
like protect_region(start, end, flags), or just all of protect_vma()
could be moved to include/asm/mmu_context.h. That way ARM can operate on
the whole region, while blackfin would add protection for every page in
the VMA as it is doing now.
i think you could use the existing framework, and perhaps optionally extend
it. maybe if i knew a little more about your "regions", i could suggest
something else.
I'll work on another patch that better merges my original ARM MPU work
into the blackfin work, and resubmit.
great, thanks
Btw, I probably should be working in whatever git tree people are
submitting patches against, rather than the 20100628 release. Which git
tree should I submit against?
that's hard to say. if current mainline (2.6.36-rc2) has everything you need
to boot a working system, then that is probably the place to base your work.
i understand though that the arm/nommu work is taking a while to get into
mainline, so that might not be feasible. in which case, you should find the
very latest uclinux tree and use that.
i know people like to base their work off a release, but in order to get
merged, the focus has to be on the latest development tree.
ok. Greg says that the core non-MMU stuff is in mainline now, so I'll
work from mainline.
Steve
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
