[Xen-devel] Re: about fixup_page_fault

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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