I want to know any difference between writing, reading and shadow page table (for example performance). I am thankful for any help or resource for that. -- Best Regards Mohamad Taghi Mir Mohamad Rezaie Iran University of Science and Technology Department of Computer Science & Engineering System Software Group _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie > Sent: 13 June 2007 15:55 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] page table question! > > I want to know any difference between writing, reading and shadow page > table (for example performance).Not sure exactly what you''re asking for: are you asking about "writable" and "non-writable" page-table vs. shadow-page-table? I believe "writable" page-table means that the guest is able to write DIRECTLY to the lower level(s) of the page-table, and as such, we "trust" the guest to do this correctly (and not map in stuff that doesn''t belong to the guest). I believe this mode isn''t normally used by Xen guests. This mode relies on the guest to correctly translate the guest-physical address to a machine physical address. Non-writable page-tables are mapped "read-only" throughout the entire page-table, and when a write occurs, the page-table is updated via the emulation of the instruction in the hypervisor. The hypervisor can check that the machine physical address is correct for the particular guest. As of currently, Shadow-mode is only used for HVM (fully virtualized) domains. In this case, the guest has a "dummy" page-table that is not used by the processor for any memory accesses, instead a "shadow" (copy) of the guest''s page-table is used. The shadow page-table is used by the processor. To make updates to the page-table appear in the shadow-page-table, the hypervisor is making sure that the guest-page-table is read-only, and when the guest writes to the page-table, we reproduce the write [with modification to reflect the difference between guest physical and machine physical address]. -- Mats> I am thankful for any help or resource for that. > > -- > Best Regards > Mohamad Taghi Mir Mohamad Rezaie > > Iran University of Science and Technology > Department of Computer Science & Engineering > System Software Group > > _______________________________________________ > 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
> > I want to know any difference between writing, reading and shadow page > > table (for example performance). > > Not sure exactly what you''re asking for: are you asking about "writable" > and "non-writable" page-table vs. shadow-page-table?"Writable pagetables" is an interface introduced for Xen 3 PV guests to update their pagetables. Previous versions of Xen required guests to be modified to make every update to their pagetables explicitly call into Xen (and explicitly batch those operations). Writeable pagetables replace this by allowing updates to the pagetables to be implemented by the guest as attempts to write directly to them. This isn''t a trusted operation, however, since Xen uses page protections to prevent unvalidated writes going through... Right now this is implemented by trapping each attempt to write to the lower levels of the pagetables and emulating it in Xen. Previous implementations were a bit more complicated but found to be unnecessary. This interface does require the guest to do physical->machine translations (which are verified by Xen before installing them), and the guest actually works with the real pagetables (subject to certain restrictions). As a result the guest can get data out of the real pagetables by doing a simple read - this operation should be as fast as native. Updating pagetables is obviously a bit slower than native because Xen has to emulate them; explicit calls to Xen''s batched update interface are used to give decent performance when lots of PTEs are being modified. Does that answer your question, Mohammad?> As of currently, Shadow-mode is only used for HVM (fully virtualized) > domains. In this case, the guest has a "dummy" page-table that is not > used by the processor for any memory accesses, instead a "shadow" (copy) > of the guest''s page-table is used. The shadow page-table is used by the > processor. To make updates to the page-table appear in the > shadow-page-table, the hypervisor is making sure that the > guest-page-table is read-only, and when the guest writes to the > page-table, we reproduce the write [with modification to reflect the > difference between guest physical and machine physical address].What Mats said :-) One thing I''ve never been clear on for shadow mode is how accessed / dirty bits get propagated to the guest pagetable from the shadow. At some point there was also support in Xen for fully translated shadowing of PV guests but I''m not sure this works now. PV guests do still get shadowed in a limited way during live migration, however. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: M.A. Williamson [mailto:maw48@hermes.cam.ac.uk] On > Behalf Of Mark Williamson > Sent: 13 June 2007 17:06 > To: xen-devel@lists.xensource.com > Cc: Petersson, Mats; MT Rezaie > Subject: Re: [Xen-devel] page table question! > > > > I want to know any difference between writing, reading > and shadow page > > > table (for example performance). > > > > Not sure exactly what you''re asking for: are you asking > about "writable" > > and "non-writable" page-table vs. shadow-page-table? > > "Writable pagetables" is an interface introduced for Xen 3 PV > guests to update > their pagetables. Previous versions of Xen required guests > to be modified to > make every update to their pagetables explicitly call into Xen (and > explicitly batch those operations). Writeable pagetables > replace this by > allowing updates to the pagetables to be implemented by the > guest as attempts > to write directly to them. This isn''t a trusted operation, > however, since > Xen uses page protections to prevent unvalidated writes going > through... > Right now this is implemented by trapping each attempt to > write to the lower > levels of the pagetables and emulating it in Xen. Previous > implementations > were a bit more complicated but found to be unnecessary.Thanks for clarifying. I seem to remember reading about a mode where the page-table isn''t "read-only" - did I just imagine that, or what?> > This interface does require the guest to do physical->machine > translations > (which are verified by Xen before installing them), and the > guest actually > works with the real pagetables (subject to certain > restrictions). As a > result the guest can get data out of the real pagetables by > doing a simple > read - this operation should be as fast as native. Updating > pagetables is > obviously a bit slower than native because Xen has to emulate > them; explicit > calls to Xen''s batched update interface are used to give > decent performance > when lots of PTEs are being modified. > > Does that answer your question, Mohammad? > > > As of currently, Shadow-mode is only used for HVM (fully > virtualized) > > domains. In this case, the guest has a "dummy" page-table > that is not > > used by the processor for any memory accesses, instead a > "shadow" (copy) > > of the guest''s page-table is used. The shadow page-table is > used by the > > processor. To make updates to the page-table appear in the > > shadow-page-table, the hypervisor is making sure that the > > guest-page-table is read-only, and when the guest writes to the > > page-table, we reproduce the write [with modification to reflect the > > difference between guest physical and machine physical address]. > > What Mats said :-)There is another mode that we haven''t mentioned yet, which is the HAP-mode (aka NPT (Nested Page-tables) from AMD, and Intel has something similar which I believe is called EPT). HAP stands for Hardware Assisted Paging. This mode is (obviously) only available in processors that have support for this feature - there are none of these available on the market just yet. The idea in this mode is that the guest doesn''t know about the machine-physical address, but we also don''t intercept page-table writes (by making the guest page-table read-only). Instead, there is a second, hypervisor-owned, page-table that translates the guest-physical address to machine-physical address. So instead of using a single page-table that is "modified" to match the guest-virtual->machine-physical, we add another layer of page-table to translate guest-physical->machine-physical address. This second page-table is normally static, so it requires no changes under normal operation. There is a performance advantage here in that we don''t have to intercept the write to the page-table. This is normally fairly expensive, so for systems where page-tables are written often, it''s definitely worth having. On systems with rare updates to the page-table, the performance advantage is much smaller, if any at all.> > One thing I''ve never been clear on for shadow mode is how > accessed / dirty > bits get propagated to the guest pagetable from the shadow.Good question. I have a feeling that the answer is "it doesn''t". HAP would probably solve this problem. -- Mats> > At some point there was also support in Xen for fully > translated shadowing of > PV guests but I''m not sure this works now. PV guests do > still get shadowed > in a limited way during live migration, however. > > Cheers, > Mark > > -- > Dave: Just a question. What use is a unicyle with no seat? > And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel! > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > "Writable pagetables" is an interface introduced for Xen 3 PV > > guests to update > > their pagetables. Previous versions of Xen required guests > > to be modified to > > make every update to their pagetables explicitly call into Xen (and > > explicitly batch those operations). Writeable pagetables > > replace this by > > allowing updates to the pagetables to be implemented by the > > guest as attempts > > to write directly to them. This isn''t a trusted operation, > > however, since > > Xen uses page protections to prevent unvalidated writes going > > through... > > Right now this is implemented by trapping each attempt to > > write to the lower > > levels of the pagetables and emulating it in Xen. Previous > > implementations > > were a bit more complicated but found to be unnecessary. > > Thanks for clarifying. I seem to remember reading about a mode where the > page-table isn''t "read-only" - did I just imagine that, or what?As far as I know normal Xen doesn''t support any mode where the guest can write directly to real pagetables without validation... I can think of two things you might have read about: 1) on intercepting an attempted write to an L1 pagetable, the wrpt code would unhook that from the pagetable hierarchy, and then make it writable. Subsequently, the guest could write to it as a normal page. A fault would occur if the CPU tried to translate a VA covered by this pagetable, at which point Xen would revalidate that pagetable for safety, then hook it back into the hierarchy. This let batching of pagetable updates be entirely implicit, but it later turned out that it performed less well than emulating each write, and using explicit batching in the guest. 2) if you compile Xen with the right options, a dom0 kernel (possibly with the right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen''s normal checks. The intent was to use this to make a kernel bootable both on native hardware (eventually using a "minixen" rather than heavyweight Xen) and paravirt. This hasn''t been investigated much, since Linux decided to pursue the paravirt-ops solution, which allows a kernel to boot native or paravirt anyway.> > One thing I''ve never been clear on for shadow mode is how > > accessed / dirty > > bits get propagated to the guest pagetable from the shadow. > > Good question. I have a feeling that the answer is "it doesn''t". HAP > would probably solve this problem.Don''t guests need the dirty bits for their memory management (e.g. mmap) to work correctly? Maybe one could do something scary like trapping reads to guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross though. HAP is definitely HAPpier :-) Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yesterday I committed a silly mistake, and then I went on hanging myself as I said in my last mail. I went to heaven, and fortunately they have internet/email here. Indeed! The God asks me to thank people like Mats, Mark, Anthony Liguori,... who are always willing to answer technical questions on the list. It is believed that not everybody can explain problems in clear and easy-to-understand way like you can do. Your posts are always very much useful, and I believe that those helps can raise and attract a lot more developers for this project. You dont know how much the community appreciate your helps! Thanks god we have people like you here! Keep posting, and you will all go to heaven :-)>From heaven, with respects,Jun On 6/14/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> > > "Writable pagetables" is an interface introduced for Xen 3 PV > > > guests to update > > > their pagetables. Previous versions of Xen required guests > > > to be modified to > > > make every update to their pagetables explicitly call into Xen (and > > > explicitly batch those operations). Writeable pagetables > > > replace this by > > > allowing updates to the pagetables to be implemented by the > > > guest as attempts > > > to write directly to them. This isn''t a trusted operation, > > > however, since > > > Xen uses page protections to prevent unvalidated writes going > > > through... > > > Right now this is implemented by trapping each attempt to > > > write to the lower > > > levels of the pagetables and emulating it in Xen. Previous > > > implementations > > > were a bit more complicated but found to be unnecessary. > > > > Thanks for clarifying. I seem to remember reading about a mode where the > > page-table isn''t "read-only" - did I just imagine that, or what? > > As far as I know normal Xen doesn''t support any mode where the guest can write > directly to real pagetables without validation... > > I can think of two things you might have read about: > > 1) on intercepting an attempted write to an L1 pagetable, the wrpt code would > unhook that from the pagetable hierarchy, and then make it writable. > Subsequently, the guest could write to it as a normal page. A fault would > occur if the CPU tried to translate a VA covered by this pagetable, at which > point Xen would revalidate that pagetable for safety, then hook it back into > the hierarchy. This let batching of pagetable updates be entirely implicit, > but it later turned out that it performed less well than emulating each > write, and using explicit batching in the guest. > > 2) if you compile Xen with the right options, a dom0 kernel (possibly with the > right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen''s > normal checks. The intent was to use this to make a kernel bootable both on > native hardware (eventually using a "minixen" rather than heavyweight Xen) > and paravirt. This hasn''t been investigated much, since Linux decided to > pursue the paravirt-ops solution, which allows a kernel to boot native or > paravirt anyway. > > > > > One thing I''ve never been clear on for shadow mode is how > > > accessed / dirty > > > bits get propagated to the guest pagetable from the shadow. > > > > Good question. I have a feeling that the answer is "it doesn''t". HAP > > would probably solve this problem. > > Don''t guests need the dirty bits for their memory management (e.g. mmap) to > work correctly? Maybe one could do something scary like trapping reads to > guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross > though. > > HAP is definitely HAPpier :-) > > Cheers, > Mark > > -- > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel! > > _______________________________________________ > 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
On 6/14/07, Jun Koi <junkoi2004@gmail.com> wrote:> Yesterday I committed a silly mistake, and then I went on hanging > myself as I said in my last mail. I went to heaven, and fortunately > they have internet/email here. Indeed! > > The God asks me to thank people like Mats, Mark, Anthony Liguori,... > who are always willing to answer technical questions on the list. It > is believed that not everybody can explain problems in clear and > easy-to-understand way like you can do. Your posts are always very > much useful, and I believe that those helps can raise and attract a > lot more developers for this project. > > You dont know how much the community appreciate your helps! Thanks god > we have people like you here! > > Keep posting, and you will all go to heaven :-)Actually this keep posting ,and you will go to heaven part is luring enough :-).Even for people like me who want to contribute and now one more reason to stick to Xen;). Good one Jun. (I hope they''ll let my message in) Regards --psr> > >From heaven, with respects, > Jun > > > On 6/14/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: > > > > "Writable pagetables" is an interface introduced for Xen 3 PV > > > > guests to update > > > > their pagetables. Previous versions of Xen required guests > > > > to be modified to > > > > make every update to their pagetables explicitly call into Xen (and > > > > explicitly batch those operations). Writeable pagetables > > > > replace this by > > > > allowing updates to the pagetables to be implemented by the > > > > guest as attempts > > > > to write directly to them. This isn''t a trusted operation, > > > > however, since > > > > Xen uses page protections to prevent unvalidated writes going > > > > through... > > > > Right now this is implemented by trapping each attempt to > > > > write to the lower > > > > levels of the pagetables and emulating it in Xen. Previous > > > > implementations > > > > were a bit more complicated but found to be unnecessary. > > > > > > Thanks for clarifying. I seem to remember reading about a mode where the > > > page-table isn''t "read-only" - did I just imagine that, or what? > > > > As far as I know normal Xen doesn''t support any mode where the guest can write > > directly to real pagetables without validation... > > > > I can think of two things you might have read about: > > > > 1) on intercepting an attempted write to an L1 pagetable, the wrpt code would > > unhook that from the pagetable hierarchy, and then make it writable. > > Subsequently, the guest could write to it as a normal page. A fault would > > occur if the CPU tried to translate a VA covered by this pagetable, at which > > point Xen would revalidate that pagetable for safety, then hook it back into > > the hierarchy. This let batching of pagetable updates be entirely implicit, > > but it later turned out that it performed less well than emulating each > > write, and using explicit batching in the guest. > > > > 2) if you compile Xen with the right options, a dom0 kernel (possibly with the > > right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen''s > > normal checks. The intent was to use this to make a kernel bootable both on > > native hardware (eventually using a "minixen" rather than heavyweight Xen) > > and paravirt. This hasn''t been investigated much, since Linux decided to > > pursue the paravirt-ops solution, which allows a kernel to boot native or > > paravirt anyway. > > > > > > > > One thing I''ve never been clear on for shadow mode is how > > > > accessed / dirty > > > > bits get propagated to the guest pagetable from the shadow. > > > > > > Good question. I have a feeling that the answer is "it doesn''t". HAP > > > would probably solve this problem. > > > > Don''t guests need the dirty bits for their memory management (e.g. mmap) to > > work correctly? Maybe one could do something scary like trapping reads to > > guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross > > though. > > > > HAP is definitely HAPpier :-) > > > > Cheers, > > Mark > > > > -- > > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > > Mark: To answer a question with a question: What use is a skateboard? > > Dave: Skateboards have wheels. > > Mark: My wheel has a wheel! > > > > _______________________________________________ > > 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 >-- --- pradeep singh rautela "Genius is 1% inspiration, and 99% perspiration" - not me :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:> > > One thing I''ve never been clear on for shadow mode is how > > > accessed / dirty > > > bits get propagated to the guest pagetable from the shadow. > > > > Good question. I have a feeling that the answer is "it doesn''t". HAP > > would probably solve this problem.When a guest pagetable entry has the Accessed bit clear, its shadow has the Present bit clear. This means we will get an extra page fault when the guest tries to read that area of memory. In the page-fault handler we write the Accessed bit into the guest entry, and replace the shadow entry with one that has the Present bit. A similar scheme (shadowing ~Dirty with ~Writeable) applies to those entries that have Dirty bits. The actual moving parts are in the _sh_propagate() function in arch/x86/mm/shadow/multi.c, which is why that function needs to be told whether it''s handling a read fault, write fault or prefetch operation.> Don''t guests need the dirty bits for their memory management (e.g. mmap) to > work correctly?Yes, although in fact Xen doesn''t quite catch all the cases where those bits should be set (certain Xen-handled operations that walk the guest pagetables instead of using the shadows) and it''s not tripped us up yet. :)> Maybe one could do something scary like trapping reads to > guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross > though.It was considered. :) (For good reasons; talk to Michael Fetterman some time.)> HAP is definitely HAPpier :-)Yep, should see a significant performance increase and eliminate a lot of moving parts. 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 I try to read the paging part code of xen-3.1.0, and I am confused about the " compat_machine_to_phys_mapping" ,what does xen do with the "CONFIG_COMPAT",and what are the differences between the "machine_to_phys_mapping" and the "compat_machine_to_phys_mapping"? Could you help me Thanks in advance Petersson, Mats 写道:> > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie >> Sent: 13 June 2007 15:55 >> To: xen-devel@lists.xensource.com >> Subject: [Xen-devel] page table question! >> >> I want to know any difference between writing, reading and shadow page >> table (for example performance). >> > > Not sure exactly what you''re asking for: are you asking about "writable" > and "non-writable" page-table vs. shadow-page-table? > > I believe "writable" page-table means that the guest is able to write > DIRECTLY to the lower level(s) of the page-table, and as such, we > "trust" the guest to do this correctly (and not map in stuff that > doesn''t belong to the guest). I believe this mode isn''t normally used by > Xen guests. This mode relies on the guest to correctly translate the > guest-physical address to a machine physical address. > > Non-writable page-tables are mapped "read-only" throughout the entire > page-table, and when a write occurs, the page-table is updated via the > emulation of the instruction in the hypervisor. The hypervisor can check > that the machine physical address is correct for the particular guest. > > As of currently, Shadow-mode is only used for HVM (fully virtualized) > domains. In this case, the guest has a "dummy" page-table that is not > used by the processor for any memory accesses, instead a "shadow" (copy) > of the guest''s page-table is used. The shadow page-table is used by the > processor. To make updates to the page-table appear in the > shadow-page-table, the hypervisor is making sure that the > guest-page-table is read-only, and when the guest writes to the > page-table, we reproduce the write [with modification to reflect the > difference between guest physical and machine physical address]. > > -- > Mats > > >> I am thankful for any help or resource for that. >> >> -- >> Best Regards >> Mohamad Taghi Mir Mohamad Rezaie >> >> Iran University of Science and Technology >> Department of Computer Science & Engineering >> System Software Group >> >> _______________________________________________ >> 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 > > > . > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I try to read the paging part code of xen-3.1.0, and I am confused about > the " compat_machine_to_phys_mapping" ,what does xen do with the > "CONFIG_COMPAT",and what are the differences between the > "machine_to_phys_mapping" and the "compat_machine_to_phys_mapping"?Compat-mode guests are 32-bit PAE guests running on a 64-bit hypervisor. Certain Xen API data structures need to be translated for compat-mode guests to access them; I guess the M2P mapping must be one of them but it''s not immediately obvious to me what the differences would be. For things like the start info / shared info page, which will also be different for compat-mode guests, it''s more obvious since at the least there are probably some fields that are 64-bit or 32-bit depending on the guest mode... Cheers, Mark> Could you help me > Thanks in advance > > Petersson, Mats 写道: > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xensource.com > >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of MT Rezaie > >> Sent: 13 June 2007 15:55 > >> To: xen-devel@lists.xensource.com > >> Subject: [Xen-devel] page table question! > >> > >> I want to know any difference between writing, reading and shadow page > >> table (for example performance). > > > > Not sure exactly what you''re asking for: are you asking about "writable" > > and "non-writable" page-table vs. shadow-page-table? > > > > I believe "writable" page-table means that the guest is able to write > > DIRECTLY to the lower level(s) of the page-table, and as such, we > > "trust" the guest to do this correctly (and not map in stuff that > > doesn''t belong to the guest). I believe this mode isn''t normally used by > > Xen guests. This mode relies on the guest to correctly translate the > > guest-physical address to a machine physical address. > > > > Non-writable page-tables are mapped "read-only" throughout the entire > > page-table, and when a write occurs, the page-table is updated via the > > emulation of the instruction in the hypervisor. The hypervisor can check > > that the machine physical address is correct for the particular guest. > > > > As of currently, Shadow-mode is only used for HVM (fully virtualized) > > domains. In this case, the guest has a "dummy" page-table that is not > > used by the processor for any memory accesses, instead a "shadow" (copy) > > of the guest''s page-table is used. The shadow page-table is used by the > > processor. To make updates to the page-table appear in the > > shadow-page-table, the hypervisor is making sure that the > > guest-page-table is read-only, and when the guest writes to the > > page-table, we reproduce the write [with modification to reflect the > > difference between guest physical and machine physical address]. > > > > -- > > Mats > > > >> I am thankful for any help or resource for that. > >> > >> -- > >> Best Regards > >> Mohamad Taghi Mir Mohamad Rezaie > >> > >> Iran University of Science and Technology > >> Department of Computer Science & Engineering > >> System Software Group > >> > >> _______________________________________________ > >> 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 > > > > > > . > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks a lot Mark! I got what I wanted. best regards Mohammad _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a counterpart pagetable for each of the guestOS process''s page table, is it ? then there will not be a small mount of memory consumption for hyperviser''s limited VA ,is it? or where are those counterpart page tables stored ? Thanks in advance Tim Deegan 写道:> At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote: > >>>> One thing I''ve never been clear on for shadow mode is how >>>> accessed / dirty >>>> bits get propagated to the guest pagetable from the shadow. >>>> >>> Good question. I have a feeling that the answer is "it doesn''t". HAP >>> would probably solve this problem. >>> > > When a guest pagetable entry has the Accessed bit clear, its shadow has > the Present bit clear. This means we will get an extra page fault when > the guest tries to read that area of memory. In the page-fault handler > we write the Accessed bit into the guest entry, and replace the shadow > entry with one that has the Present bit. A similar scheme (shadowing > ~Dirty with ~Writeable) applies to those entries that have Dirty bits. > > The actual moving parts are in the _sh_propagate() function in > arch/x86/mm/shadow/multi.c, which is why that function needs to be told > whether it''s handling a read fault, write fault or prefetch operation. > > >> Don''t guests need the dirty bits for their memory management (e.g. mmap) to >> work correctly? >> > > Yes, although in fact Xen doesn''t quite catch all the cases where those > bits should be set (certain Xen-handled operations that walk the guest > pagetables instead of using the shadows) and it''s not tripped us up > yet. :) > > >> Maybe one could do something scary like trapping reads to >> guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross >> though. >> > > It was considered. :) (For good reasons; talk to Michael Fetterman > some time.) > > >> HAP is definitely HAPpier :-) >> > > Yep, should see a significant performance increase and eliminate a lot > of moving parts. > > Tim. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a > counterpart pagetable for each of the guestOS process''s page table, is > it ? then there will not be a small mount of memory consumption for > hyperviser''s limited VA ,is it? or where are those counterpart page > tables stored ?As far as I know, the VMM only needs one extra table per guest, not per process. This describes the "guest physical" -> "machine physical" mapping. Guest virtual addresses are then translated by walking the guest pagetable (guest virtual -> guest physical) and then the physical->machine table for that guest (maintained by the VMM) to get a real host address. Cheers, Mark> Thanks in advance > > Tim Deegan 写道: > > At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote: > >>>> One thing I''ve never been clear on for shadow mode is how > >>>> accessed / dirty > >>>> bits get propagated to the guest pagetable from the shadow. > >>> > >>> Good question. I have a feeling that the answer is "it doesn''t". HAP > >>> would probably solve this problem. > > > > When a guest pagetable entry has the Accessed bit clear, its shadow has > > the Present bit clear. This means we will get an extra page fault when > > the guest tries to read that area of memory. In the page-fault handler > > we write the Accessed bit into the guest entry, and replace the shadow > > entry with one that has the Present bit. A similar scheme (shadowing > > ~Dirty with ~Writeable) applies to those entries that have Dirty bits. > > > > The actual moving parts are in the _sh_propagate() function in > > arch/x86/mm/shadow/multi.c, which is why that function needs to be told > > whether it''s handling a read fault, write fault or prefetch operation. > > > >> Don''t guests need the dirty bits for their memory management (e.g. mmap) > >> to work correctly? > > > > Yes, although in fact Xen doesn''t quite catch all the cases where those > > bits should be set (certain Xen-handled operations that walk the guest > > pagetables instead of using the shadows) and it''s not tripped us up > > yet. :) > > > >> Maybe one could do something scary like trapping reads to > >> guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gross > >> though. > > > > It was considered. :) (For good reasons; talk to Michael Fetterman > > some time.) > > > >> HAP is definitely HAPpier :-) > > > > Yep, should see a significant performance increase and eliminate a lot > > of moving parts. > > > > Tim.-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 2007-12-08 at 22:26 +0800, tgh wrote:> hi > In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a > counterpart pagetable for each of the guestOS process''s page table, is > it ?No. It''s similar to shadow paging in that two different sets of page tables are in use. But then, returning to some of your original questions above in this thread: *This* is where hardware consults a P2M table: The nested page table does not, like a shadow table, translate virtual to machine, but pseudo-physical to machine addresses.> then there will not be a small mount of memory consumption for > hyperviser''s limited VA ,is it? or where are those counterpart page > tables stored ?Or do you mean the part of the VM dedicated to the hypervisor? Code running in root mode is running in "host linear" address space, i.e. the nested page table, not the guest''s one. Actually, that''s one major benefit of nested paging: counteraction "address space compression". So, the guest system takes two levels of translation, while the host (Xen, in this case) takes only one. Hope this helps. Clarify your question if it doesn''t. regards, daniel -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
some issues are still confuesed , Daniel Stodden 写道:> >> then there will not be a small mount of memory consumption for >> hyperviser''s limited VA ,is it? or where are those counterpart page >> tables stored ? >> > > Or do you mean the part of the VM dedicated to the hypervisor? Code > running in root mode is running in "host linear" address space, i.e. the > nested page table, not the guest''s one. Actually, that''s one major > benefit of nested paging: counteraction "address space compression". >nested page table ,for the AMD NPT ,is stored in the dom0 linear space, not in the hypervisor virtual address ,is it? or what is the meaning of "that''s one major benefit of nested paging: counteraction "address space compression".",and what about the Intel EPT, is it similar ,or how does it work, I am still comfused about the hypervisor'' limited virtual address space, it wont be used for storing the EPT or NPT, is it? or what about the hypervisor''s virtual address space in the AMD or Intel-vt?how much space is it? or what is tricks behind, could you give me a more detailed explanation about NPT and EPT another one ,"the guest system takes two levels of translation, while the host(Xen, in this case) takes only one" , what is the meaning? guest does virtual->physical, while physical->machine is translated by xen, is it? what is the tricks, by say, guest takes two levels of translation? Thanks in advance> So, the guest system takes two levels of translation, while the host > (Xen, in this case) takes only one. > > Hope this helps. Clarify your question if it doesn''t. > > regards, > daniel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 11:07 +0800 on 16 Dec (1197803269), tgh wrote:> nested page table ,for the AMD NPT ,is stored in the dom0 linear space, > not in the hypervisor virtual address ,is it? or what is the meaning of > "that''s one major benefit of nested paging: counteraction "address space > compression".",and what about the Intel EPT, is it similar ,or how does > it work, I am still comfused about the hypervisor'' limited virtual > address space, it wont be used for storing the EPT or NPT, is it? or > what about the hypervisor''s virtual address space in the AMD or > Intel-vt?how much space is it? or what is tricks behind, could you give > me a more detailed explanation about NPT and EPTNPT is described in volume 2 of AMD''s Architecture Programmer''s Manual. http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html I don''t know of any publically available documentation on EPT, but there are some details in Jun Nakajima''s slides from the recent Xen Summit. http://xen.org/xensummit/xensummit_fall_2007.html Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems. [Company #5334508: XenSource UK Ltd, reg''d c/o EC2Y 5EB, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel