>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Wednesday, December 17, 2008 4:35 PM
>
>On 17/12/2008 08:32, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>> Consider copy_from_guest() applied to a PV guest with dirty
>>> logging enabled.
>>> The #PF handler should fix up faults when accessing guest
>>> address space via
>>> shadow page tables, even when the access happens within Xen.
>>
>> If Xen access guest address space intentionally like a hypercall
>> parameter, such fix up is desired. However what about an random
>> illegal access in Xen with faulting address happening to fall into
>> guest address space?
>
>Well, HVM guests obviously have a separate address space, so
>no issue there.
>For a PV guest -- yes, Xen will then erroneously access guest
>address space
>instead of crashing. But this is no worse than what would
>happen if running
>without shadow page tables (i.e., dirty logging disabled).
>Fortunately Xen
>has no bugs. ;-)
>
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. :-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home