| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] pagetable pinning question
Hi, Zachary:
I can't describe how grateful I'm for your detailed, clear and
professional answer!
Definitely a high-ranking in FAQ!!
Thanks so much!
-- Bin
On 6 Feb 2004, at 01:28, Zachary Amsden wrote:
This is a good question, as all this terminology suffers from
potential overloading of the word "linear". The linear recursive map
works as follows:
Register %cr3 contains a physical page frame which points to the
current PDP. This physical page contains the physical frame addresses
of all the second level page tables. One of these entries is
special... it contains the physical frame address of the PDP itself.
The index of this entry now corresponds to the high 10 bits of a
virtual memory address. Accesses to this 4Mb region of virtual memory
are translated through the PDP, which points to the actual (likely
non-contiguous) physical page tables. So you have effectively mapped
the non-contiguous PTEs into the 4Mb contiguous (i.e. linear) virtual
memory region corresponding to the PDP index. This greatly simplifies
some operations, since you can use the hardware to map the page tables
and access them as a giant array. This is the linear map.
The map is actually recursive, since the PDP itself will be mapped
into the same VM region. So if your special index was say 767 (as in
NetBSD), then the 4Mb VM region at 0xbfc00000 would contain a linear
mapping of your page tables. The page at 0xbfeff000 would contain the
PDP itself, and the virtual address 0xbfeffbfc would contain the
physical address of the PDP.
You can also use other slots in the PDP to map other processes page
tables, which might be useful for shared memory access or implementing
fork(). This is what causes the problems with reference accounting,
since you have the same page being used both as a PDP and a PTP, with
possible circular references.
Zachary Amsden
zamsden@xxxxxxxxx
Bin Ren wrote:
Hi,
I'm a bit confused by parts of the discussion going here. Can anyone
explain the difference between linear page table and normal page
table?
Linux page tables are all linear, i.e. contiguous page table entries
correspond to contiguous virtual pages. Is this right? How about
NetBSD?
How can one page directory be mapped from another page directory?
My understanding is: (maybe wrong) each process has only one
page directory and 1024 page tables. Each page directory and page
table fits into one page (on 32-bit computers with 4k page size).
Not all page tables are allocated physical page frames initially.
During
a context switch from process A to process B, A's PD and PTs can be
swapped out (in face of memory shortage), releasing physical page
frames for use by B. So, how can one PD be mapped by another PD?
What am I missing here?
Thanks,
Bin
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home