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] Re: about fixup_page_fault

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: about fixup_page_fault
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 17 Dec 2008 09:04:04 +0000
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
Delivery-date: Wed, 17 Dec 2008 01:04:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD603BB497F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aclf9g7ST2T7twmkTliVD2zN2EnoWgAKqw6yAAAPVYAAAFX/AgAAMZVQAADUh1s=
Thread-topic: about fixup_page_fault
User-agent: Microsoft-Entourage/12.14.0.081024
On 17/12/2008 08:50, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> For PV, it looks OK since fixup guest address space also allows
> xen forwarding progress as xen/pv guest share one address space.
> However regarding to seperate address spaces in HVM shadow
> case, is it a wrong action to search shadow page table for page
> fault which is instead expected to be checked against monitor
> page table? It's possible for one faulting address to have valid
> mapping in shadow, but not in monitor table, and then make
> faulting cpu in dead loop (fault, check shadow, re-execute, and
> fault again...).
> 
> Above dead loop is observed when one of my colleague is fixing
> one xenoprof issue, where null pointer is not checked for de-
> reference in xen. Yes, the cause could be deduced by dumping
> cpu stack, but is it possible to check such condition and then
> throw out a 'fatal page fault' in console which is more informative?
> Of course this is not bug issue, and more useful to developer. :-)

A Xen fault shouldn't cause a lookup in guest tables for HVM guests.

I think the issue here is actually that shadow code places some mapping of
its own at address 0. We've had this issue before, where it stops NULL
dereferences from crashing...

It is surely something like that since most guests are (sensibly) not going
to have a mapping at address 0. So it's unlikely that a mapping has actually
erroneously been propagated from the guest.

CC'ing Tim and Gianluca. They probably know what this 0-based mapping is,
and also whether it is feasible to move it.

 -- Keir



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