On 07/31/2013 03:11 PM, Stefan Kristiansson wrote:
On Wed, Jul 31, 2013 at 12:14 PM, Jonas Bonn <jo...@southpole.se> wrote:
On 31 July 2013 09:48, Stefan Kristiansson
<stefan.kristians...@saunalahti.fi> wrote:
On Tue, Jul 30, 2013 at 02:35:01PM +0200, Jonas Bonn wrote:
I agree on close to all of the above, except I think we should keep the xMMUPR
registers, but change the indexing from 0-7 (so 8 sets of protection bits).
Not so much because I think that the flexibility is needed, but because
using a "lookup table" to translate the X/W/U bits into
SRE/SXE/SWE/URE/UXE/UWE actually makes sense.
e.g. for the DTLB case:
X | W | U
---------
0 | 0 | 0 = SRE0
0 | 0 | 1 = SRE1 | URE1
0 | 1 | 0 = SRE2 | SWE2
0 | 1 | 1 = SRE3 | SWE3 | URE3 | UWE3
1 | 0 | 0 = SRE4
1 | 0 | 1 = SRE5 | URE5
1 | 1 | 0 = SRE6 | SWE7
1 | 1 | 1 = SRE7 | SWE7 | URE7 | UWE7
Software would need a pair of shift and mask operations to pick entries
out of the "lookup table" and hardware can easily do bitfield table lookups
directly from the register.
So we need two 32-bit registers to implement a look-up table for 3
bits with a well-defined meaning (X/W/U)?
Strictly speaking, one 32-bit and one 16-bit register.
Heh... 48 bits then. Still, 48 > 3.
I'm not going to put up a big fight about keeping the xMMUPR
registers, but they _are_ in the arch spec as of now and even though
X/W/U are well defined and sufficient for the Linux case,
is that true for all other cases?
I say "yes, it's sufficient". I hereby put the challenge to the list to
come up with a _reasonable_ combination that's not possible with the
above 3 bits, along with an explanation of the use case that requires it.
I agree, they are in the arch spec but they are also (presumably)
implemented nowhere. Dropping them is a net win in terms of
architectural complexity. We may need to bump the version register and
refuse to run on "old versions w/ hardware TLB reload", but such
implementations don't exist anyway so it's a simple check that will
never trigger. (TLB HW reload can be checked in one of the CFGR regs, I
noticed).
It's of course still possible to do the lookup table approach without
the actual registers by using a static map to X/W/U,
both in software and hardware.
That must be a simpler HW implementation... right? For SW it's
definitely better.
In the software approach you most likely would do it without the
registers anyway.
While we're at it, the bit order in DMMUPR should probably be changed
to match the one in DTLBTR, asi is now they don't match.
i.e. DMMUPR = UWE|URE|SWE|SRE and DTLBTR = SWE|SRE|UWE|URE
If we keep the PR around, then I agree.
Regarding the PTE, isn't PRESENT == VALID?
Yes, it would seem to be.
----------------------
So how do we get 2MB huge pages... here's my suggestion.
Top-level page directory
---------------------------
0x0000... | 8-bit index entry, L=0 |
---------------------------
0x0020... | Empty |
to ~ ... ~
0x00e0... | Empty |
---------------------------
0x0100... | Next 8-bit index entry, L=1 |
---------------------------
0x0120... | 2 MB page entry (L=1) |
to ~ ... ~
0x01e0... | 2 MB page entry (L=1) |
---------------------------
0x0200... | Next 8-bit index entry, L=0 |
| ~~~ |
~ ~
The top-level page directory is an 8kB page, and it's 8-bit indexing
makes it sparsely populated. If we find that the L bit (huge page)
is set on an 8-bit indexed entry, then we could do a second indexing
on the remaining three bits (11 bit index total) to find the entry
to the 2MB huge page in the "free space".
This could get us 2MB huge pages and we could then keep the ATB
stuff around for the less useful 16MB huge pages.
This all plays reasonably nicely with the arch spec we've got today.
What would need clarifying is that these huge pages are 2MB and not
16MB, but this is all so vague in the spec as it stands and
otherwise unimplemented in practice that it ought to be doable.
This is of course bending the meaning of the L bit, perhaps that should
be renamed then?
Because now you always have a two-level structure, but with the difference
that you are pointing back into the page directory in the second level.
Would it *have* to point into the page directory though?
Or could we use the entry fetched from the 8-bit indexed to get the
table pointer (and this could happen to point back into the pgd on
Linux as a memory saving optimization)?
No, the 8-bit indexed PPN can't point to another page-table in the L=1
case because the case where the next 3 bits are 0 (11-bit index ==
8-bit index) needs to point to a valid page.
My suggestion may be too complex, though; getting 1MB pages into the
second-level table may make more sense.
/Jonas
I kept the full quote of your message in my response, since I believe
you by mistake pressed reply instead of reply all.
Good catch! Thank you!
/Jonas
_______________________________________________
Linux mailing list
Linux@lists.openrisc.net
http://lists.openrisc.net/listinfo/linux
