[Xen-devel] RE: about fixup_page_fault

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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