[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] handling emulation fine-grained memory protection
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] handling emulation fine-grained memory protection |
Date: |
Mon, 3 Jul 2017 17:40:19 +0100 |
On 3 July 2017 at 17:07, Richard Henderson <address@hidden> wrote:
> On 07/03/2017 03:04 AM, Peter Maydell wrote:
>> 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.
>
>
> It's close.. We need 3 bits that do not overlap any requested alignment.
>
> Does the v7m profile have 8-byte aligned operations? I see that STREXD is
> out, and I can't think of anything else. So bits 8, 16, 32 are up for
> grabs, which does fit a 64-byte page minimum.
Looking at section B5.4 in the v8M ARM ARM, it lists only
alignment faults for non-halfword-aligned halfword accesses
and for non-word-aligned various, so we don't need 8-byte
alignment checks.
> That said...
>
>> 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?
>
>
> I think it would be simpler to have a separate thing, since the regular
> subpage handling requires memory allocation.
>
> I would just think about a bit, TLB_PROT_RECHECK or so, that not only takes
> the slow path through the helper, but also the slow path back through
> tlb_fill.
>
> Since these are defined by system registers, I can imagine there can only be
> a few pages for which this fine grained handling might apply any any one
> time. This would certainly be preferable to reducing the effectiveness of
> the entire TLB by a factor of 16.
Yes, that was somewhat my feeling too -- really tiny TLB pages
are not very nice, and most pages probably won't be finegrained.
thanks
-- PMM