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 on mapped pages with reserved bits set

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Page fault on mapped pages with reserved bits set
From: Trammell Hudson <hudson@xxxxxxxxxxxxxx>
Date: Wed, 20 Jun 2007 17:59:10 -0400
Delivery-date: Wed, 20 Jun 2007 14:57:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: Mutt/1.5.10i
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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