Return to BSD News archive
Xref: sserve comp.unix.bsd:1820 comp.unix.wizards:26067 comp.unix.questions:24023 Path: sserve!manuel!munnari.oz.au!uunet!usc!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek From: torek@horse.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.bsd,comp.unix.wizards,comp.unix.questions Subject: Re: 4.3bsd Usrptmap Date: 2 Jul 1992 11:34:29 GMT Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 25 Message-ID: <24316@dog.ee.lbl.gov> References: <l4et57INN34i@ack.cs.utexas.edu> <24291@dog.ee.lbl.gov> Reply-To: torek@horse.ee.lbl.gov (Chris Torek) NNTP-Posting-Host: 128.3.112.15 In article <24291@dog.ee.lbl.gov> I wrote: >Usrptmap[] is the page table that maps the user page tables. This >first-level page table must be in physically contiguous memory (per >the VAX architecture). ... Bill Jolitz (yes, that Bill Jolitz :-) ) pointed out that this is wrong: the VAX hardware looks up user page tables in kernel virtual space. It is only the Sysmap[] PTEs that must be in physically contiguous space. He added that: >In the Univ. Utah emulation of the "old" VM, it was easier to arrange >things with consecutive physical, which might be where the confusion >comes! (I have never dealt with the old Utah code myself, so I think I just must have confused the VAX page lookup with other multilevel PTE schemes. This kind of hardware lookup eventually runs out of levels and has to fall back on some simple scheme, usually `physical base address plus offset'. There are other methods, such as Sun's weird Sun-3 and SPARCstation MMUs and MIPS and HP-PA software translation schemes, which give you a different set of drawbacks. :-) .) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov