Xen devel - Jun 2007 - Page fault on mapped pages with reserved bits set

I''m porting a light weight kernel to run under the Xen hypervisor
and have run into a problem while trying to switch to my page tables
on x86-64.  After a minor problem with switching to the new PML4
table that was cleared up when Mark Williamson suggested mapping
everything read-only in the current map before switching, as well
as switching the memory management code to use the hypervisor calls
to manipulate the pages and I now fault on the first write after
the new mapping.

The console error message is:

(XEN) Unhandled page fault in domain 33 on VCPU 0 (ec=0003)
(XEN) Pagetable walk from 0000006000520978:
(XEN)  L4[0x000] = 0000000026838025 0000000000000011
(XEN)  L3[0x180] = 00000000330a9025 0000000000000018
(XEN)  L2[0x002] = 0000000023d6d025 0000000000000024 
(XEN)  L1[0x120] = 0010000026fd1027 0000000000000520
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 33 (vcpu#0) crashed on cpu#0:

The mapping corresponds with what was setup, other than the user and
reserved bits being set for the L1 entry.  Since this is x86-64,
I understand that Xen has set the user bit for my guest kernel,
but according to my paging extensions overview, the RSV bit may
trigger a page fault:

   If set (RSV=1), may cause a page fault.  Setting this bit only
   causes a page fault during page translation.  If the referenced
   page entry is in the TLB, then setting this bit, and referencing
   the page will not cause a page fault.  If the entry is not in
   the TLB, or gets flushed from the TLB, then the next reference
   to this page will cause a page fault.  The page fault error code
   on the stack will have the RSV bit set (bit-3).

I can''t handle the page fault, since my kernel''s page fault
routine
faults if it tries to do anything that writes to memory, such as
push a return address on the stack.  To generate the error message
above I had to disable my kernel''s trap table to let Xen handle it.
Otherwise the fault address is in my handler rather than in the
instruction after setting MMUEXT_BASE_PTR.

Any suggestions on things to try?

Thanks!
-- Trammell

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

On 20/6/07 22:59, "Trammell Hudson" <hudson@osresearch.net>
wrote:
> I can''t handle the page fault, since my kernel''s page
fault routine
> faults if it tries to do anything that writes to memory, such as
> push a return address on the stack.  To generate the error message
> above I had to disable my kernel''s trap table to let Xen handle
it.
> Otherwise the fault address is in my handler rather than in the
> instruction after setting MMUEXT_BASE_PTR.
> 
> Any suggestions on things to try?
It''s a protection violation on a write, because none of your page
directory
entries have bit 1 (_PAGE_RW) set. That bit gets ANDed down the entire page
walk, so it needs to be set at every level for the page to actually be
writable.

 -- Keir



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

On Wed, Jun 20, 2007 at 11:10:14PM +0100, Keir Fraser
wrote:
> It''s a protection violation on a write, because none of your page
directory
> entries have bit 1 (_PAGE_RW) set. That bit gets ANDed down the entire page
> walk, so it needs to be set at every level for the page to actually be
> writable.
Super!  That was it.

The kernel was originally written for a CPU and system that allowed
the ring 0 code to write to memory, even if it was flagged as
non-writable.  Moving it into ring 3 has been problematic in other
areas, too, so it isn''t booting all the way yet, but is making much
quicker progress now!

-- Trammell

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