Hi,
I have some questions about Shadow page table in Xen.
1.
Xen used shadow-1, shadow-2, and shadow-3 from beginning to now.
(http://blog.xen.org/index.php/2008/08/27/xen-33-feature-shadow-3/)
In Xen 3.3, it re-use out-of-sync, which is used in Shadow-1.
Shadow-1. Its method of propagating changes from guest pagetables
to the shadow pagetables was as follows:
1. Remove write access to any guest pagetable.
2. When a guest attempts to write to the guest pagetable, mark it
out-of-sync, add the page to the out-of-sync list and give write
permission.
3. On the next page fault or cr3 write, take each page from the
out-of-sync list and:
- resync the page: look for changes to the guest pagetable,
propagate those entries into the shadow pagetable
- remove write permission, and clear the out-of-sync bit.
My question is that, dose step 2 trap into Xen hypervisor?
2.
I think there are 2 kinds of page fault. 1) normal page fault in guest,
which should be handled by guest; 2) invoked by guest updating the page
table, which should be handled by Xen.
So, if there''s a page-miss fault in guest, how many times it will trap
into Xen?
First, page miss, trap into Xen. Xen finds out it''s the 1st kind fault,
then it go back to guest to handle it.
Then, in guest, when it updates the page table to fix the page fault,
it will invoke the 2nd kind fault, which will trap into Xen again.
Am I right?
3.
For the user space part, are the attribute bits of the entries
in Guest page table and Shadow page table the same?
Thanks,
Wu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi, At 09:46 +0100 on 26 May (1243331218), Wu Bingzheng wrote:> Shadow-1. Its method of propagating changes from guest pagetables > to the shadow pagetables was as follows: > > 1. Remove write access to any guest pagetable. > 2. When a guest attempts to write to the guest pagetable, mark it > out-of-sync, add the page to the out-of-sync list and give write > permission. > 3. On the next page fault or cr3 write, take each page from the > out-of-sync list and: > - resync the page: look for changes to the guest pagetable, > propagate those entries into the shadow pagetable > - remove write permission, and clear the out-of-sync bit. > > My question is that, dose step 2 trap into Xen hypervisor?Yes, of course. It''s done in the #PF handler.> 2. > I think there are 2 kinds of page fault. 1) normal page fault in guest, > which should be handled by guest; 2) invoked by guest updating the page > table, which should be handled by Xen. > > So, if there''s a page-miss fault in guest, how many times it will trap into Xen? > First, page miss, trap into Xen. Xen finds out it''s the 1st kind fault, > then it go back to guest to handle it > Then, in guest, when it updates the page table to fix the page fault, > it will invoke the 2nd kind fault, which will trap into Xen again. > > Am I right?Yes; and in some circumstances there can be more than two faults (e.g. if the guest''s new entry hasn''t got the Accessed bit set).> 3. > For the user space part, are the attribute bits of the entries > in Guest page table and Shadow page table the same?No; the only guarantee is that the shadow entry won''t contain more access rights than the guest entry. For PTEs that map MMIO space we try to do the right thing with the caching attributes too. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks so much! Wu>Hi, > >At 09:46 +0100 on 26 May (1243331218), Wu Bingzheng wrote: >> Shadow-1. Its method of propagating changes from guest pagetables >> to the shadow pagetables was as follows: >> >> 1. Remove write access to any guest pagetable. >> 2. When a guest attempts to write to the guest pagetable, mark it >> out-of-sync, add the page to the out-of-sync list and give write >> permission. >> 3. On the next page fault or cr3 write, take each page from the >> out-of-sync list and: >> - resync the page: look for changes to the guest pagetable, >> propagate those entries into the shadow pagetable >> - remove write permission, and clear the out-of-sync bit. >> >> My question is that, dose step 2 trap into Xen hypervisor? > >Yes, of course. It''s done in the #PF handler. > >> 2. >> I think there are 2 kinds of page fault. 1) normal page fault in guest, >> which should be handled by guest; 2) invoked by guest updating the page >> table, which should be handled by Xen. >> >> So, if there''s a page-miss fault in guest, how many times it will trap into Xen? >> First, page miss, trap into Xen. Xen finds out it''s the 1st kind fault, >> then it go back to guest to handle it >> Then, in guest, when it updates the page table to fix the page fault, >> it will invoke the 2nd kind fault, which will trap into Xen again. >> >> Am I right? > >Yes; and in some circumstances there can be more than two faults >(e.g. if the guest''s new entry hasn''t got the Accessed bit set). > >> 3. >> For the user space part, are the attribute bits of the entries >> in Guest page table and Shadow page table the same? > >No; the only guarantee is that the shadow entry won''t contain more >access rights than the guest entry. For PTEs that map MMIO space we try >to do the right thing with the caching attributes too. > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@citrix.com> >Principal Software Engineer, Citrix Systems (R&D) Ltd. >[Company #02300071, SL9 0DZ, UK.] > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wu Bingzheng
2009-May-27 02:47 UTC
Re:Re:Re: [Xen-devel] Questions about shadow page table.
Hi, I have another question about Shadow. If a process writes a read-only page in guest OS, how does the page-fault handler deal with it? In sh_page_fault() [xen/arch/x86/mm/shadow/multi.c], which part deals with this case? In the label `emulate` and `not_a_shadow_fault` ? But the points where jumps to the label `emulate` seems not to be this case (write readonly pages in guest), but seems to emulate accesses to page tables. Thanks, Wu> >At 09:46 +0100 on 26 May (1243331218), Wu Bingzheng wrote: >> Shadow-1. Its method of propagating changes from guest pagetables >> to the shadow pagetables was as follows: >> >> 1. Remove write access to any guest pagetable. >> 2. When a guest attempts to write to the guest pagetable, mark it >> out-of-sync, add the page to the out-of-sync list and give write >> permission. >> 3. On the next page fault or cr3 write, take each page from the >> out-of-sync list and: >> - resync the page: look for changes to the guest pagetable, >> propagate those entries into the shadow pagetable >> - remove write permission, and clear the out-of-sync bit. >> >> My question is that, dose step 2 trap into Xen hypervisor? > >Yes, of course. It''s done in the #PF handler. > >> 2. >> I think there are 2 kinds of page fault. 1) normal page fault in guest, >> which should be handled by guest; 2) invoked by guest updating the page >> table, which should be handled by Xen. >> >> So, if there''s a page-miss fault in guest, how many times it will trap into Xen? >> First, page miss, trap into Xen. Xen finds out it''s the 1st kind fault, >> then it go back to guest to handle it >> Then, in guest, when it updates the page table to fix the page fault, >> it will invoke the 2nd kind fault, which will trap into Xen again. >> >> Am I right? > >Yes; and in some circumstances there can be more than two faults >(e.g. if the guest''s new entry hasn''t got the Accessed bit set). > >> 3. >> For the user space part, are the attribute bits of the entries >> in Guest page table and Shadow page table the same? > >No; the only guarantee is that the shadow entry won''t contain more >access rights than the guest entry. For PTEs that map MMIO space we try >to do the right thing with the caching attributes too. > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@citrix.com> >Principal Software Engineer, Citrix Systems (R&D) Ltd. >[Company #02300071, SL9 0DZ, UK.] > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel穿越地震带 纪念汶川地震一周年 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wu Bingzheng
2009-May-27 03:09 UTC
Re:Re:Re:Re: [Xen-devel] Questions about shadow page table.
In another word, how can page-fault handler distinguish the shadow-page-fault and non-shadow-page-fault? When reading it''s code, I skip all the code enabled only #if SHADOW_OPTIMIZATIONS, is that ok? Hi, I have another question about Shadow. If a process writes a read-only page in guest OS, how does the page-fault handler deal with it? In sh_page_fault() [xen/arch/x86/mm/shadow/multi.c], which part deals with this case? In the label `emulate` and `not_a_shadow_fault` ? But the points where jumps to the label `emulate` seems not to be this case (write readonly pages in guest), but seems to emulate accesses to page tables. Thanks, Wu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2009-May-27 08:12 UTC
Re: Re:Re:Re: [Xen-devel] Questions about shadow page table.
At 04:09 +0100 on 27 May (1243397391), Wu Bingzheng wrote:> In another word, how can page-fault handler distinguish the > shadow-page-fault and non-shadow-page-fault?By looking at the guest''s own pagetables (not the shadows) and the error code, and figuring out whether this would have been a pagefault on bare metal. Yes, the not_a_shadow_fault path is for this.> When reading it''s code, I skip all the code enabled only #if > SHADOW_OPTIMIZATIONS, is that ok?You''ll miss out on some quite major changes to the shadow code (the whole of what''s been called "shadow 3"), but it should still make sense. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wu Bingzheng
2009-May-27 09:10 UTC
Re:Re: Re:Re:Re: [Xen-devel] Questions about shadow page table.
在2009-05-27，"Tim Deegan" <Tim.Deegan@citrix.com> 写道：>At 04:09 +0100 on 27 May (1243397391), Wu Bingzheng wrote: >> In another word, how can page-fault handler distinguish the >> shadow-page-fault and non-shadow-page-fault? > >By looking at the guest''s own pagetables (not the shadows) and the error >code, and figuring out whether this would have been a pagefault on bare >metal. Yes, the not_a_shadow_fault path is for this.Thanks. Would you like to point out where exactly to make the decision? I guess this should be at the beginning of sh_page_fault(), and also out of the [#if SHADOW_OPTIMIZATIONS, #endif], but I didn''t find it. Is it sh_mfn_is_a_page_table() ? Thanks, Wu> >> When reading it''s code, I skip all the code enabled only #if >> SHADOW_OPTIMIZATIONS, is that ok? > >You''ll miss out on some quite major changes to the shadow code (the >whole of what''s been called "shadow 3"), but it should still make sense. > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@citrix.com> >Principal Software Engineer, Citrix Systems (R&D) Ltd. >[Company #02300071, SL9 0DZ, UK.]_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2009-May-27 09:40 UTC
Re: Re: Re:Re:Re: [Xen-devel] Questions about shadow page table.
At 10:10 +0100 on 27 May (1243419042), Wu Bingzheng wrote:> ??2009-05-27??"Tim Deegan" <Tim.Deegan@citrix.com> ?????? > >At 04:09 +0100 on 27 May (1243397391), Wu Bingzheng wrote: > >> In another word, how can page-fault handler distinguish the > >> shadow-page-fault and non-shadow-page-fault? > > > >By looking at the guest''s own pagetables (not the shadows) and the error > >code, and figuring out whether this would have been a pagefault on bare > >metal. Yes, the not_a_shadow_fault path is for this.Actually, all "goto propagate" paths in sh_page_fault() do this too; the not_a_shadow_fault label also has some lock handling that''s required on some paths.> Thanks. Would you like to point out where exactly to make the > decision?Typical guest faults are caught at the first "goto propagate", based on the return code of sh_walk_guest_tables(). Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wu Bingzheng
2009-May-29 09:03 UTC
Re:Re: Re: Re:Re:Re: [Xen-devel] Questions about shadow page table.
Thanks so much. I have another question. If a process''s page is read-write in guest''s page table, but the Xen hypervisor sets it as read-only in shadow page table on some purpose. What happens if the process writes this page? Is this case treated as guest page fault or shadow page fault? Thanks, Wu>At 10:10 +0100 on 27 May (1243419042), Wu Bingzheng wrote: >> ??2009-05-27??"Tim Deegan" <Tim.Deegan@citrix.com> ?????? >> >At 04:09 +0100 on 27 May (1243397391), Wu Bingzheng wrote: >> >> In another word, how can page-fault handler distinguish the >> >> shadow-page-fault and non-shadow-page-fault? >> > >> >By looking at the guest''s own pagetables (not the shadows) and the error >> >code, and figuring out whether this would have been a pagefault on bare >> >metal. Yes, the not_a_shadow_fault path is for this. > >Actually, all "goto propagate" paths in sh_page_fault() do this too; the >not_a_shadow_fault label also has some lock handling that''s required on >some paths. > >> Thanks. Would you like to point out where exactly to make the >> decision? > >Typical guest faults are caught at the first "goto propagate", based on >the return code of sh_walk_guest_tables(). > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@citrix.com> >Principal Software Engineer, Citrix Systems (R&D) Ltd. >[Company #02300071, SL9 0DZ, UK.] > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel