jack@cwi.nl (Jack Jansen) (07/24/87)
Well, every time I change something in my MMU code, I get bit by this, and usually the problem dissapears after some hacking, but now I would like to get rid of this once and for all: If you change a secondary page table entry, should you invalidate the entry (by putting the address in the EIA) *before* or *after* modifying the in-core entry? I.e. does the MMU just forget about the SPT entry, or does it write it back to main memory before it does? And, the same question, but now for changing PTB1. The system I'm working on is based on a 32016 and a 32082, but given National's fantastic upwards compatability, that shouldn't make much of a difference, I guess. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
amos@nsta.UUCP (Amos Shapir) (07/26/87)
(I'm posting this to educate other people who may have similar problems)
The 32082 (and also the 32382) keep a Translation Look-aside Buffer
(TLB) in which it looks to find recent translations before searching the
translation tables; writing an address to the Error/Invalid Address
(EIA) register (IVAR on the 32382), and also changing the Page Table
Base registers (PTB) purges that address from the TLB.
When changing a mapping of a page in any table, the best strategy is of
course to make sure that the address is not used while we change it. If
that is not possible, we have to guarantee that no incosistency exists
between the address kept in the TLB and that in the tables. The way I
see it (just off the top of my head) is: 1. Invalidate the Page Table
Entry (PTE) 2. Purge that entry from the TLB; any references to that
address should now be caught by the page fault handler and delayed until
we finish changing it). 3. Make the change in the PTE; 4. Set it to
valid.
If you interchange 1 and 2 (that was what the question was about), as
long as the entry is valid, any reference to it will just bring it back
into the TLB again.
Unix uses the former method, i.e. a process is blocked while its PTE's
are changing, so the exact order of actions is not important.
--
Amos Shapir (My other cpu is a NS32532)
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261
amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N