[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] paging


  • To: "PUCCETTI Armand" <armand.puccetti@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Huang2, Wei" <Wei.Huang2@xxxxxxx>
  • Date: Wed, 2 Aug 2006 17:37:26 -0500
  • Delivery-date: Wed, 02 Aug 2006 15:38:07 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aca2TCggAsPDF/hyQdqLj6uBaygI4QAMy8FQ
  • Thread-topic: [Xen-devel] paging

Your questions are answered in the following [].

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of PUCCETTI
Armand
Sent: Wednesday, August 02, 2006 10:55 AM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.