Messages in this thread | | | Date | Sun, 02 May 1999 02:34:01 -0700 | From | "H. Peter Anvin" <> | Subject | Re: 64bit port |
| |
Rogier Wolff wrote: > > > > > > This is the crux of it, see my other mail. When you have seperate, > > > software controlled, instruction and data TLBs you can pull all of > > > this off cleanly I believe. > > > > I actually think that you don't need either of those constraints. What > > you *do* need, however, are separate r, w and x permissions on each > > page. Also the instruction set needs to be amenable to these kinds of > > scans; most RISCs are. You only need to keep each page in one of two > > states: writable or executable. When you write to an executable page, > > you get a trap, and flip it to the other state; when you execute, you > > again get a trap, scan the page, and put it back in the executable > > state. > > Yes, and because Dave knows the Sparc architecture inside and out, he > knows he's going to implement this at the tlb level. > > You're thinking about permissions in the page table. Sparcs don't have > a hardware paging table, you get to fill the TLB in software, and so > at that time you get to do any additional checks that you may want... >
All I said was that it wasn't necessary. I know what you can do with a software-managed TLB, but I *also* know that the TLB-filling code tends to be incredibly performance-critical.
Oh yes, and you really need to worry about pages that are aliased.
-hpa
-- "The user's computer downloads the ActiveX code and simulates a 'Blue Screen' crash, a generally benign event most users are familiar with and that would not necessarily arouse suspicions." -- Security exploit description on http://www.zks.net/p3/how.asp
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |