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 ? -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
