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: 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: about fixup_page_fault
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 17 Dec 2008 17:20:30 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
Delivery-date: Wed, 17 Dec 2008 01:20:55 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C56E7104.204C3%keir.fraser@xxxxxxxxxxxxx>
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>
References: <0A882F4D99BBF6449D58E61AAFD7EDD603BB497F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C56E7104.204C3%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aclf9g7ST2T7twmkTliVD2zN2EnoWgAKqw6yAAAPVYAAAFX/AgAAMZVQAADUh1sAAHz8YA==
Thread-topic: about fixup_page_fault
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Wednesday, December 17, 2008 5:04 PM
>
>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.
>

I'm told by Xiaowei that bug happens when guest is still in
hvmloader, where faked 1:1 page table is used as guest
page table. In that case sh_page_fault will enter fixed shadow
fault path since page 0 mapping exists.

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