marlon@daisy.UUCP (Marlon Pearson) (04/12/90)
Reading through "The Design and Implementation of the 4.3 BSD Unix* Operating System" I understand most of it so far but I would like to ask a couple questions (not all at once). On p. 80 it is talking about low-level context switching. It reads "... To make switching user structures as efficient as possible on the VAX, the system maps the physical memory associated with each process's user structure to a fixed location at the top of the user-mode virtual address space. (This location is also at a fixed virtual address in the kernel's address space.) Since the user-mode virtual memory mapping is defined by values maintained in a process's PCB, switching between processes, and between user structures, simply becomes a matter of swapping PCBs..." I am confused about a couple things. I am familiar with mapping virtual addresses to physical but not the other way around. So the first sentence has got me. The last sentence I understand but the parenthesized sentence I just kind of ignore because I figure once I understand the first I will get that one too. A further explanation would be welcomed. Thanks, Marlon *Register Trademark ----- -- Marlon of the Jungle marlon@daisy.com | marlon@daisy.UUCP | uunet!daisy!marlon | spam!spam!spam!eggs!spam
chris@mimsy.umd.edu (Chris Torek) (04/14/90)
In article <34@daisy.UUCP> marlon@daisy.UUCP (Marlon Pearson) writes: >... "The Design and Implementation of the 4.3 BSD Unix* Operating System" >... On p. 80 it is talking about low-level context switching. It reads >"... To make switching user structures as efficient as possible on the >VAX, the system maps the physical memory associated with each process's >user structure to a fixed location at the top of the user-mode virtual >address space. ..." >I am confused about a couple things. I am familiar with mapping virtual >addresses to physical but not the other way around. So the first sentence >has got me. It does not mean `We go out and find the physical address, then magically map it to a particular virtual address,' but rather `We choose a set of physical pages in which to store a u. area, then set up a page map so that, when we context switch into this process, these pages show up at a particular virtual address (0x80000000 - UPAGES*NBPG).' >"(This location is also at a fixed virtual address in the >kernel's address space.)" This really means `and by the way, we also give it a particular kernel space virtual address'---in this case, since kernel code can reach into user space directly, this is also 0x80000000 - UPAGES*NBPG. If you calculate this value you get 0x7fffec00; if you run `nm /vmunix' you will find that `_u' is an absolute symbol whose value is 0x7fffec00. In other words, the compiler (or more precisely, the linker) knows that `&u' is `0x7fffec00', always. No matter which process is running at the time, the address of, e.g., u.u_ofile[] is the same. The actual value of u.u_ofile[0] (the file for descriptor 0 for the current process) changes when the current process changes (during a context switch), but the address of u.u_ofile[0] is always the same. There is actually some more trickery with `double mapping' of physical pages during fork() and during swapping, using Forkmap/forkutl, etc. None of this is relevant to ordinary context switching, however. Note that another approach (easy on VM machines) is simply to map the u. area of each process into kernel virtual space only, giving each one a different address, and maintain a pointer to the current `struct user', changing it at each context switch. This has some unfortunate effects on signals, however (which currently `bounce off' user-space code stored in the u. area). It also makes addressing more difficult (have to track down the current u. pointer). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris