[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: 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.
>

Agree. But it looks like current sh_page_fault only checks 
guest_mode in some paths. For example, my quick search
seems to say no such check for fixed shadow fault path.
Maybe an explicit check on guest mode at entry is clearer
to state above guideline. But definitely I may overlook some
lines...

>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...

Yeah, I recall that issue, which was from shadow linear mapping. :-)

>
>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.
>

I'm also a bit suspicious now why address 0 doesn't cause
crash. May need more thinking.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.