On 08/26/2010 06:07 PM, Mike Frysinger wrote:
On Thursday, August 26, 2010 18:45:08 Steve Longerbeam wrote:
On 08/26/2010 12:04 PM, Mike Frysinger wrote:
On Thursday, August 26, 2010 14:19:41 Steve Longerbeam wrote:
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).
i dont understand why running out of entries is a problem. we run out of
entries too as you cant cover 512MiB of SDRAM with 16 entries. we simply
take an exception when this occurs and in the exception handler, we use
a basic round-robin replacement scheme to install a valid PTE (assuming
of course the user has a valid mapping for the excepting address). then
we return to the user process and it continues on.
why wont this scheme work for you too ?
no, you're right, that would work. Of course, it would have a bigger
memory usage for the page tables, and a performance hit (with my
implementation when a process is running there are no faults). But it is
more inline with how MMU kernels work, and it adds process-to-process
protection too.
we used a bitmap to save on memory and execution. each bit representing a 4k
chunk. this is the "page_rwx_mask" and similar stuff that appears in the
Blackfin asm/mmu*.h headers.
ok, I'll take a closer look.
have you done performance measurements to see the overhead with the MPU turned
on in your scheme compared to off ? doing something like a ffmpeg decode to
another file. if the performance trade offs of your current scheme (per-
mapping) is significant compared to the classic per-page, then it is worth
while to extend the MPU Kconfig option so people can select per-page or per-
mapping schema.
yes, if performance degrades a lot for per-page compared to my current
scheme, that would be worthwhile to offer both options. OTOH, other
people may have different requirements (better protection being more
important than memory footprint or performance, or vice-versa). So it
might make sense to offer both options anyway.
btw, i dont think it was mentioned earlier, but these ranges you're working
with ... do they have alignment requirements ?
yes, but it varies by ARM cores. For instance, on the SC100, the MPU
regions must be 64-byte aligned, but the ARM940T has the same alignment
requirement as blackfin (alignment = size).
the thing about Blackfin PTEs
is that they must be aligned according to the size they represent. so if it
is a 4KiB mapping, it must be aligned to 4KiB. if it's 1MiB, it must be
aligned to 1MiB. it'd be nice if that alignment restriction wasnt there as we
could then do a flexible range mapping similar to what you have.
-mike
_______________________________________________
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
