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/
Home Products Support Community News


Re: [Xen-devel] Setting up page directories and tables

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Setting up page directories and tables
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 1 May 2007 17:27:14 +0100
Cc: Joel Weinberger <joel@xxxxxxxxxxxx>, Dave Pacheco <dap@xxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Tue, 01 May 2007 09:27:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <2d88d46a0704271311m4f41aa6bna46cc903bb619f32@xxxxxxxxxxxxxx>
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>
References: <2d88d46a0704271311m4f41aa6bna46cc903bb619f32@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
> This OS is designed for 32-bit x86 (no PAE), so I intend to use a two-level
> paging system. Each process has a page directory - one page with entries
> which point to page tables, whose entries describe actual pages. As far as
> I can tell, this is what's done in the Mini-OS source, with page
> directories referred to as L1 page tables, and what I'm calling page tables
> referred to as L2 page tables.

I think you've got this backwards: in Xen code, L1 page tables are the leaf 
nodes, L2 are their parents, L3 are their parents, etc etc.


> So when creating a process, I do the following:
>     allocate a page P for the process's page directory
>     fill P with zeros
>     update the existing page table mapping for P (previously set up by what
> is essentially the build_pagetable() code from Mini-OS) to give it L1_PROT
> & ~_PAGE_RW
>         (using HYPERVISOR_mmu_update(...))
>     pin the page (using HYPERVISOR_mmuext_op({MMUEXT_PIN_L1_TABLE,
> ...}...))
> All of these steps succeed (the hypercall returns 0, and the argument
> indicating how many updates succeeded is 1 in both cases). But later, when
> switching into the context of this process, I try to update the user base
> pointer with
>  HYPERVISOR_mmuext_op({MMUEXT_NEW_USER_BASEPTR, mfn of P}...).
> This call fails (returns -1, and indicates that 0 operations succeeded).
> Why might that be? As I've established, the page is zero'd out (so it's not
> invalid), and it seems to be mapped properly (not writable, pinned L1 page
> table). So why would this operation fail?
> Thanks in advance,
> Dave Pacheco

Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>