|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Execution Flow when Guest Page Fault
At 15:35 29/07/2007, Peter Teoh wrote:
I would like to know approximately the overall execution flow when
the guest O/S page fault - how is the page fault transfer to a page
fault in the host O/S?
I don't have source-code here, so I can't give you exactly which
functions and where the code flows through. Here's what I can do "from memory".
It depends on whether you're running PV or HVM guest... Here is a
brief run-through of both:
Paravirtual guest:
1. Page-fault in guest -> hypervisor page-fault handler (in
arch/x86/x86_{32,64}/entry.S I think)
2. do_pagefault in hypervisor (arch/x86traps.c)
-- Here there are checks to see if the page-fault is
"guest-fault" or "special case" - special case is handled by
hypervisor and then seen as "fixed", so the guest will not see these
faults. This is for example updates to the page-table itself, where
the hypervisor needs to "check" the page-table entry to verify that
the guest isn't doing something wrong (like mapping memory that
doesn't belong to the guest)
3. If the page-fault isn't "special", the hypervisor forwards the
call to the guest. In PV-mode, the hypervisor is given a "callback"
by the guest to handle any faults the guest can accept, so a guest
page-fault-handler is given by this function (called something like
set_trap, I think).
Fully virtual guest (this refers to SVM code, but the VT (VMX) code
is nearly identical, so you should be able to follow the path there
by replacing SVM with VMX in relevant places):
1. #VMEXIT with page-fault exitcode (0x4E from memory) - ends up at
the instruction after "VMRUN" in arch/x86/hvm/svm/x86_{32,64}/exits.S
2. svm_do_pagefault()
3. shadow_fault()
4. If page-fault not dealt with in shadow-fault (which also deals
with special page-faults such as page-table updates and MMIO hardware
emulation), it is forwarded to the guest via the "inject exception"
mechanism (svm_inject_exception ?).
5. vmrun in .../exits.S
[paths are relative to the "xen" directory in the source tree]
There has been other discussions on this subject in the past, so some
searching in the archive may give you some more info and ideas.
--
Mats
Thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|