WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Page fault handling for Xen guests

To: xen-devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Page fault handling for Xen guests
From: Simon Kagstrom <simon.kagstrom@xxxxxx>
Date: Wed, 08 Feb 2006 14:36:31 +0100
Delivery-date: Wed, 08 Feb 2006 13:47:36 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
Hello!

I'm trying to understand how the Xen memory management works from a
guest OS perspective. I made a small figure to show how a page fault
is handled, and wanted to see if I've understood things
correctly. I'll add the description to the Wiki provided I didn't mix
things up. I've attached the figure in this mail.


We assume that an application causes a page fault on e.g., code in a
shared library, i.e. code that is in physical memory but not mapped to
the application. We'll assume that the page directory exists, but does
not have a page table or a page mapped for the faulting virtual
address. The following will then happen (steps are outlined in the
figure):

1. Xen receives the page fault and delivers it to the guest through
   the trap table (installed by HYPERVISOR_set_trap_table()). The
   guest will thereafter lookup a physical page to map into the
   application.

    page_fault_handler(virt_addr) {
      ...
      pgdir_entry = virt_to_pgdir(virt_addr);
      pgtab_entry = virt_to_pgtab(virt_addr);
      phys_page = virt_to_phys(virt_addr);
      ...

2. The guest looks up the page directory and finds that there exists
   no mapping (to a page table) for that address.

3. To get a new page table page, the guest will

   * Get a new page (get_page()) for the page table
   * Translate the pseudo-physical address of the page to a machine
     address through the machine->physical translation table, e.g.,

      pgtab = get_page();
      pgtab_mach_addr = machine_to_physical(pgtab);

4. The guest inserts the machine address of the page table page into
   the page directory through HYPERVISOR_MMU_update(), i.e., something
   like (simplified syntax)

    HYPERVISOR_mmu_update(pgdir_entry | MMU_NORMAL_PT_UPDATE, pgtab_mach_addr | 
PGTAB_PROTECTION, ...);

   (the page table page is now accessible)

5. The guest must then instruct Xen to pin this page as a page table
   page (simplified syntax):

    HYPERVISOR_mmuext_op(MMUEXT_PIN_L2_TABLE, pgtab_mach_addr, ...);

6. Finally the guest will map the physical page into the page table

    phys_page_mach_addr = machine_to_physical(phys_page);    
    HYPERVISOR_mmuext_op(pgtab_entry | MMU_NORMAL_PT_UPDATE, 
phys_page_mach_addr | PROTECTION, ...);


Have I understood this more or less correctly? If so, I'll add the
description and figure to the Wiki.

// Simon

PNG image

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Page fault handling for Xen guests, Simon Kagstrom <=