Hi All, I am trying to understand Shadow page fault handling in Xen for x86_64 in Intel VT-x As per my understanding when guest can update it own page table without causing VM exit in xen when some process requires some memory (pages) this will cause page fault and control goes to guest OS the guest then allocate page from its own psuedo address space and make entries in guest page table which contain mapping of virtual to psuedo physical memory and But when actual write occurs to that page, page fault occurs which will cause vm exit in xen. Xen then will update the page mfn in shadow page table and return control back to guest by vn entry. Is this understanding it correct? so there would be only one vn exit/entry? please do reply back Thanks in advance Jeet __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 14:39 +0530 on 02 Mar (1172846389), jeet wrote:> As per my understanding when guest can update it own page table without causing VM exit in xenNo -- once a page is recognised as a page table by Xen, the guest is no longer allowed to write directly to it. We trap and emulate any instructions that write to known page tables, so that we can keep the shadow page tables up to date.> when some process requires some memory (pages) this will cause page fault and control goes to guest OS > the guest then allocate page from its own psuedo address space and make entries in guest page table which contain > mapping of virtual to psuedo physical memory and > > But when actual write occurs to that page, page fault occurs which will cause vm exit in xen. > > Xen then will update the page mfn in shadow page table and return control back to guest by vn entry. > > Is this understanding it correct? so there would be only one vn exit/entry?There are at least two VMEXITs needed. Typically the first is for the original page fault, which is reflected back to the guest. The second is caused by the guest''s fault-handler writing to guest pagetables; Xen intercepts that write and updates the shadow pagetables to match. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Tim Thanks for your prompt reply. But I am currently looking into xen 3.0.3. Is shadow code implementation in xen 3.0.3 is same as explained by you in reply? Jeet ----- Original Message ---- From: Tim Deegan <Tim.Deegan@xensource.com> To: jeet <jeet_sat12@yahoo.co.in> Cc: xen-devel@lists.xensource.com Sent: Friday, 2 March, 2007 3:06:46 PM Subject: Re: [Xen-devel] page fault handling in Xen At 14:39 +0530 on 02 Mar (1172846389), jeet wrote:> As per my understanding when guest can update it own page table without causing VM exit in xenNo -- once a page is recognised as a page table by Xen, the guest is no longer allowed to write directly to it. We trap and emulate any instructions that write to known page tables, so that we can keep the shadow page tables up to date.> when some process requires some memory (pages) this will cause page fault and control goes to guest OS > the guest then allocate page from its own psuedo address space and make entries in guest page table which contain > mapping of virtual to psuedo physical memory and > > But when actual write occurs to that page, page fault occurs which will cause vm exit in xen. > > Xen then will update the page mfn in shadow page table and return control back to guest by vn entry. > > Is this understanding it correct? so there would be only one vn exit/entry?There are at least two VMEXITs needed. Typically the first is for the original page fault, which is reflected back to the guest. The second is caused by the guest''s fault-handler writing to guest pagetables; Xen intercepts that write and updates the shadow pagetables to match. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 17:36 +0530 on 02 Mar (1172856988), jeet wrote:> Is shadow code implementation in xen 3.0.3 is same as explained by you in reply?Yes. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Tim
in case of second fault that will occur when guest will try to write in
GPT(which is readonly)
and faulting address would be of Page table in which the write is attempted. VM
exit will occur and xen would execute
following code
in file xen-3.0.3_0-src\xen\arch\mm\shadow\multi.c in the page fault handler
static int sh_page_fault(struct vcpu *v,
unsigned long va,
struct cpu_user_regs *regs)
{
...
...
[line 2949]
// Was it a write fault?
//
if ( regs->error_code & PFEC_write_access )
{
// //if error is write access and RW permission is not present
if ( unlikely(!(accumulated_gflags & _PAGE_RW)) )
{
perfc_incrc(shadow_fault_bail_ro_mapping);
goto not_a_shadow_fault;
}
...
..
Above code will execute and in inner unlikely condition will be true as PT table
is read only and error is write_access
and control will go to not_a_shadow_fault?
so when the emulation code would be executed for the write that has been
performed on read only guest PT for adding entry in
guest page table by guest?
Have I missed some thing here in understanding
kindly provide your valuable reply
jeet
----- Original Message ----
From: Tim Deegan <Tim.Deegan@xensource.com>
To: jeet <jeet_sat12@yahoo.co.in>
Cc: xen-devel@lists.xensource.com
Sent: Friday, 2 March, 2007 7:05:43 PM
Subject: Re: [Xen-devel] page fault handling in Xen
At 17:36 +0530 on 02 Mar (1172856988), jeet wrote:> Is shadow code implementation in xen 3.0.3 is same as explained by you in
reply?
Yes.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 5/3/07 06:29, "jeet" <jeet_sat12@yahoo.co.in> wrote:> Above code will execute and in inner unlikely condition will be true as PT > table is read only and error is write_access > and control will go to not_a_shadow_fault? > > so when the emulation code would be executed for the write that has been > performed on read only guest PT for adding entry in > guest page table by guest? > > Have I missed some thing here in understandingYes: guest PTs are mapped with write permissions in the guest PTs. It''s only in the shadow PTs that the guest PTs are mapped read-only. The test on accumulated_gflags is looking at the access permissions in the guest PTs. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir thanks for your reply.I have some more queries In HVM when guest is executing then processor looks into shadow page table for address translation. as shadow PT contains the guest pt page readonly mapping of guest level 1 page table, on which guest OS is trying to write a address of new page. 1 this would cause second VMEXit in Xen. so would faulting address be virtual address of that Guest PT page or of the shadow PT page which guest is trying to write? jeet> Above code will execute and in inner unlikely condition will be true as PT > table is read only and error is write_access > and control will go to not_a_shadow_fault? > > so when the emulation code would be executed for the write that has been > performed on read only guest PT for adding entry in > guest page table by guest? > > Have I missed some thing here in understandingYes: guest PTs are mapped with write permissions in the guest PTs. It''s only in the shadow PTs that the guest PTs are mapped read-only. The test on accumulated_gflags is looking at the access permissions in the guest PTs. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 18:39 +0530 on 05 Mar (1173119943), jeet wrote:> so would faulting address be virtual address of that Guest PT page or of the shadow PT page which guest is trying to write?The faulting address is always the VA which the processor is writing to (in this case, the guest''s mapping of its own PT page). Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Above code will execute and in inner unlikely condition will be true as PT > table is read only and error is write_access > and control will go to not_a_shadow_fault? > > so when the emulation code would be executed for the write that has been > performed on read only guest PT for adding entry in > guest page table by guest? > > Have I missed some thing here in understanding| Yes: guest PTs are mapped with write permissions in the guest PTs. It''s only | in the shadow PTs that the guest PTs are mapped read-only. The test on | accumulated_gflags is looking at the access permissions in the guest PTs. | | -- Keir Does this mean that on every new entry in level 4 guest page table will cause recursive page faults to create all the entries from level 4 till level 1 shadow page table? Jeet _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel