4

I'm confused about this statement:

From http://web.stanford.edu/class/cs140/projects/pintos/pintos_4.html#SEC63:

In Pintos, every user virtual page is aliased to its kernel virtual page.

I thought the kernel would just be able to use the user virtual address to refer to the user page, with the kernel virtual addresses above it. In the image below, for instance, wouldn't the entire VAS just be from 0 to 4GB, and the user virtual address space would be restricted to addresses below PHYS_BASE, while the kernel could also access the addresses above it?

virtual memory map
(from http://web.stanford.edu/class/cs140/cgi-bin/section/10sp-proj3.pdf)

This doesn't seem to be how it works though, as the PintOS documentation continues:

You must manage these aliases somehow. For example, your code could check and update the accessed and dirty bits for both addresses. Alternatively, the kernel could avoid the problem by only accessing user data through the user virtual address.

This implies that the kernel could access the user data through a separate kernel virtual address. I'm not sure why the two addresses would be different.

Thanks for any clarification.

newt
  • 199
  • 2
  • 12
  • Hmm.. is this the answer? "The kernel cannot directly manipulate memory that is not mapped into the kernel's address space. The kernel, in other words, needs its own virtual address for any memory it must touch directly. Thus, for many years, the maximum amount of physical memory that could be handled by the kernel was the amount that could be mapped into the kernel's portion of the virtual address space, minus the space needed for the kernel code itself." from [http://www.makelinux.net/ldd3/chp-15-sect-1](http://www.makelinux.net/ldd3/chp-15-sect-1) – newt Jan 07 '15 at 08:34
  • But then how could the kernel "avoid the problem by only accessing user data through the user virtual address"? – newt Jan 07 '15 at 08:42

1 Answers1

2

To access a page, it needs to be mapped in your current virtual address space.

So if the kernel wants to access a user page there are 2 solutions :

  • Map the page in our current address space, the kernel's address space, and make sure the two pages table entries stay consistent (you don't stricly have to keep it consistent, but you really want to).
  • Switch to an address space where that page is already mapped, the user's own address space

Your kernel seems to be picking option 1, which is a good thing for performance. Switching to another address space and back takes quite a lot time. It could pick option 2 instead and switch to the user's address space every time it wants to access a user page, this would possibly make the code simpler by avoiding some bookkeeping, but that would be awfully slow.

tux3
  • 7,171
  • 6
  • 39
  • 51
  • For option 2, if the kernel switches to the user's own address space to access the page, that means it is in user mode now, right? Doesn't that mean it doesn't have any of the kernel privileges anymore to do whatever it was it wanted to do to the user page? – newt Jan 07 '15 at 19:19
  • 1
    No, you can switch address space without going to user mode. On x86 to switch address space you just have to load a new value in cr3. To go to usermode you have to do some tricks with an iret instruction. Totally different things. cr3 is the register that contains a pointer to your top-level paging structure. – tux3 Jan 07 '15 at 19:21