> 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.
Cheers,
Mark
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home