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. 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? 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. 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. Stefan _______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux
