paging

paging

[PUCCETTI Armand]

I have a few easy questions about the xen code doing paging on AMD64.

How is the page translation function virt-to-phys (AMD64 arch programmer 
manual, page 147)
implemented ? Refining,

- In file /xen/include/asm-x86/page.h: what are the functions 
lXe_get_pfn, lXe_get_intpte, lXe_get_paddr, lXe_get_page, lXe_from_paddr 
(for X=1,..4) doing?

- One set of functions puzzles me:  l4e_to_l3e, l3e_to_l2e and 
l2e_to_l1e. The comment says "Pagetable
walking"... but what does this mean?  do they help to move from  one 
page map to another?

- In what variables are the real page tables (l4 to l1) stored?

- Does the code implement only long-mode page translation for AMD64?

- Is there anything explaining page.h, page_alloc.c and mm.c ?....

thanks and sorry for the trivial questions.
 
Armand

RE: paging

[Huang2, Wei]

Your questions are answered in the following [].

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of PUCCETTI
Armand
Sent: Wednesday, August 02, 2006 10:55 AM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] paging

I have a few easy questions about the xen code doing paging on AMD64.

How is the page translation function virt-to-phys (AMD64 arch programmer

manual, page 147)
implemented ? Refining,

- In file /xen/include/asm-x86/page.h: what are the functions 
lXe_get_pfn, lXe_get_intpte, lXe_get_paddr, lXe_get_page, lXe_from_paddr

(for X=1,..4) doing?

[[[[
lXe_get_pfn: this function returns physical frame number (PFN) pointed
by this pagetable entry.

lXe_get_intpte: this function returns the integer representation of
pagetable entry. For instance, in 4-Kbyte Non-PAE paging,
l1e_get_intpte() gives you a 32-bit integer same as Figure 5.5 on page
153.

lXe_get_paddr: returns the physical address of page table pointed by
this entry. "Usually", paddr = (pfn << PAGE_SHIFT).

lXe_get_page: returns a pointer of struct page_info. Xen maintains an
array of page_info (Xen frame structure array). Each page of machine
memory has one corresponding element in this array. 

lXe_from_paddr: generate a pagetable entry using a given physical
address. 
]]]]


- One set of functions puzzles me:  l4e_to_l3e, l3e_to_l2e and 
l2e_to_l1e. The comment says "Pagetable
walking"... but what does this mean?  do they help to move from  one 
page map to another?

[[[
The answer is yes. They will help you get to the first entry of
next-level page tables. The steps are: 1) figure out the physical
address (paddr) implied in this entry; 2) translate it into a virtual
address; and 3) cast into type of the next-level pagetable entry.
]]]

- In what variables are the real page tables (l4 to l1) stored?

[[[[
Not sure what you are asking about. The physical address of
highest-level page table is stored in CR3. Each entry of page table
contains a physical address pointing to next level page table (well, if
it is present). Whenever there is a page fault, CPU will walk the table
starting from CR3.

The manual clearly describes the implementation of different paging
modes.
]]]]

- Does the code implement only long-mode page translation for AMD64?

[[[[
page.h (in asm-x86) is generic enough for different page translations.
Some AMD64 specific implementations can be found inside page.h in
x86_64. 
]]]]

- Is there anything explaining page.h, page_alloc.c and mm.c ?....

[[[[
As far as I know, the answer is no. You have to either read the code
yourself or ask questions in this mailing list.
]]]]

thanks and sorry for the trivial questions.
 
Armand

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel