Re: page fault handling in Xen

Re: page fault handling in Xen

[Keir Fraser]

On 8 Oct 2005, at 23:39, Jonathan M. McCune wrote:

> We're curious about page fault handling in Xen-devel.  In particular, 
> during kernel boot-up, the kernel tests if the CPU "honours the WP 
> bit". This causes a page fault with error code 3 (expected behavior).  
> Does Xen still make a copy of the execution stack frame on the guest 
> OS stack, as specified in the original "Xen and the Art of 
> Virtualization" paper?  There is a footnote here that suggests that 
> using a pre-agreed shared memory location might be a better option.  
> Has this change been implemented?
>
> After the WP-test page fault is taken, what is supposed to happen from 
> Xen's perspective on the return from the page fault handler?  In 
> normal linux, the exception handler changes its own return address 
> (i.e., modifies the EIP register) to be the "fixup" address.  Does 
> this still happen with XenoLinux, or does the hypervisor get involved?

Everything works as on native, pretty much, except that the page-fault 
stack frame is extended by one word to contain the faulting linear 
address (because the guest cannot directly access %cr2).

  -- Keir

page fault handling in Xen

[Jonathan M. McCune]

[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

Hello,

We're curious about page fault handling in Xen-devel.  In particular, 
during kernel boot-up, the kernel tests if the CPU "honours the WP bit". 
This causes a page fault with error code 3 (expected behavior).  Does 
Xen still make a copy of the execution stack frame on the guest OS 
stack, as specified in the original "Xen and the Art of Virtualization" 
paper?  There is a footnote here that suggests that using a pre-agreed 
shared memory location might be a better option.  Has this change been 
implemented?

After the WP-test page fault is taken, what is supposed to happen from 
Xen's perspective on the return from the page fault handler?  In normal 
linux, the exception handler changes its own return address (i.e., 
modifies the EIP register) to be the "fixup" address.  Does this still 
happen with XenoLinux, or does the hypervisor get involved?

Thanks,
-Jon


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

page fault handling in Xen

[jeet]

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/

Re: page fault handling in Xen

[Tim Deegan]

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 xen

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

Re: page fault handling in Xen

[jeet]

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 xen

No -- 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/

Re: page fault handling in Xen

[Tim Deegan]

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

Re: page fault handling in Xen

[jeet]

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/

Re: page fault handling in Xen

[Keir Fraser]

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

Re: page fault handling in Xen

[jeet]

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



_______________________________________________
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/

Re: page fault handling in Xen

[Tim Deegan]

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

Re: page fault handling in Xen

[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 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/