[Qemu-devel] handling emulation fine-grained memory protection

[Peter Maydell]

For the ARM v7M microcontrollers we currently treat their memory
protection unit like a funny kind of MMU that only has a 1:1
address mapping. This basically works but it means that we can
only support protection regions which are a multiple of 1K in
size and on a 1K address boundary (because that's what we define
as the "page size" for it). The real hardware lets you define
protection regions on a granularity down to 64 bytes (both size
and address).

So far we've got away with this, but I think only because the
payloads we've tested haven't really used the MPU much or at all.
With v8M I expect the MPU (and its secure/non-secure cousin the
Security Attribution Unit) to be much more heavily used, so it
would be nice if we could lift this limitation somehow.

Does anybody have any good ideas for how this ought to be done?
We could wind down the "page size" for these CPUs (since we
now have runtime-configurable-page-size for ARM CPUs this
shouldn't compromise the A profile cores which can stick to
1K or 4K pages) but I don't think we can get down as low as
64 bytes due to all the things we keep in the low bits of
TLB entries.

I'm guessing we'd need to have "this page has fine grained
protection regions" imply "take the slow path" and then do
the protection check in the slow path. Alex Graf pointed out
to me a while back that we already have a data structure for
handling sub-page-sized things in the slow path (the subpage
handling in the memory system), but can we easily (or otherwise)
use it, or would it be simpler just to have a separate thing?

There are probably some awkward corner cases too, for instance
translate.c code would have to cope with the fact that it would
now be possible for the first address in a page to be executable
but later addresses in the same page not be executable...

Any thoughts/ideas/suggestions?

thanks
-- PMM