On Sun, Jul 28, 2013 at 10:31:47PM +0200, Henrik Nordström wrote:
> sön 2013-07-28 klockan 07:02 +0300 skrev Stefan Kristiansson:
> 
> > The biggest difference is that the arch spec defines a seperate register
> > (xMMUPR) which holds a table of protection bits, and the PP INDEX field
> > of the pte is used to pick out the "right" protection flags from that.
> > In our Linux port on the other hand, it has been chosen to not follow
> > this and embed the protection bits straight into the pte (which of
> > course is perfectly fine as it was designed for software tlb reload).
> > So, the question is, should we change Linux to be compliant with the
> > arch specs definition of the ptes and start using a PP index field or
> > change the arch spec to allow usages of the Linux definition?
> 
> Is there any pros/cons for the different approaches?
> 

You tell me ;)
Perhaps the whole original idea behind the PP INDEX field was
to save bits in the PTE and make it flexible, but IMO it just
makes things more complicated.

> What approach do other architectures use?

The closest thing I could find to the PP INDEX field in any other
architecture is the ACC bit field in sparc v8 [1], but if I understand things
correctly, that is mapped to a static table.

And if I read the ARM code right, I think they have seperate definitions
for the PTEs on the Linux and hardware side, residing in different memory
areas. I don't think we should do it like that though.

Stefan

[1] http://www.sparc.org/standards/V8.pdf, page 248
_______________________________________________
Linux mailing list
Linux@lists.openrisc.net
http://lists.openrisc.net/listinfo/linux

Reply via email to