From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 16 Mar 2005 21:41:12 -0700 From: "Ronald G. Minnich" To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] strongarm question Topicbox-Message-UUID: 253b1f70-ead0-11e9-9d60-3106f5b1d025 ON the strongarm there is a PID register which is interesting. When non-zero, for VA in the range 0..32M (bits 24..0), the PID register is ORed in to bits 30..25. The effect is to add 32M offsets to the address in 32M increments, i.e. if PID is set to 1 then all address in the range 0..32M will be issued to VA 32M..64M. But only VA in the base range 0..32M are so modified. on bitsy, PID is always set to 1. So, all 0M..32M addresses should issue as VA 32M..64M. (ignore the comment at the top of mmu.c about how pid is used, it appears to be wrong. The PID register never changes AFAIK). Each proc on bitsy can be at most 32M. So the proc struct carries with it all the l1 ptes for the process -- 32 in all. Other than that, the global l1table is constant and unchanging, and contains l1 entries at the top for kernel VA. What I can't understand is that on bitsy, for mmuswitch(), the code copies the up->l1table to l1table[0], NOT to l1table[32M>>20] as I would expect. In other words, if the proc VA gets modified to have 32M added to it, don't you want to modify the l1table in the range 32M..64M, since the process VA will be in that range? Obviously, bitsy works, so there's something I'm missing here. The question is, ... what? The other wacky thing is that even when I'm running in full kernel VA (0xcxxxxxxx), I can't zero out the low-VA PTEs in l1table -- I have to leave them in or bad things happen. I know my SP, SB ,etc. are ok, and PC is up in high addresses. Any ideas of what to look for here? This is the last step between me and a running *init* thanks ron