Hi, I have a question about memory page tables in Xen. As far as I understood, every modification to page table will go through Xen(hypervisor). Is it so that all page tables are actually allocated in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case that Xen(hypervisor) needs to maintain a page table for each process running in every domain? Thanks Haifeng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Nov 28, 2007 4:19 PM, Haifeng He <hehaifeng2nd@gmail.com> wrote:> Hi, > > I have a question about memory page tables in Xen. As far as I > understood, every modification > to page table will go through Xen(hypervisor). Is it so that all page > tables are actually allocated > in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case > that Xen(hypervisor) needs to > maintain a page table for each process running in every domain?In which context you are asking this? HVM guests or PV guests? Thanks> > Thanks > > Haifeng > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- -- pradeep singh rautela "question = ( to ) ? be : ! be;" -- Wm. Shakespeare _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
In my understanding, in PV, page table is allocated within guest OS, however, every update will go through xen via explicit hypercalls. in HVM, those update will be intercepted by xen. Please correct me if I''m wrong. On Nov 28, 2007 5:49 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote:> Hi, > > I have a question about memory page tables in Xen. As far as I > understood, every modification > to page table will go through Xen(hypervisor). Is it so that all page > tables are actually allocated > in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case > that Xen(hypervisor) needs to > maintain a page table for each process running in every domain? > > Thanks > > Haifeng > > _______________________________________________ > 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
Thanks for answering my question. I am talking about PV mode. What about shadow page table? Does it mean, Xen will keep (real) copies of page tables? Thanks Haifeng On Nov 28, 2007 7:10 AM, weiming <zephyr.zhao@gmail.com> wrote:> In my understanding, in PV, page table is allocated within guest OS, > however, every update will go through xen via explicit hypercalls. > in HVM, those update will be intercepted by xen. > > Please correct me if I''m wrong. > > > > On Nov 28, 2007 5:49 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > > > > > > > Hi, > > > > I have a question about memory page tables in Xen. As far as I > > understood, every modification > > to page table will go through Xen(hypervisor). Is it so that all page > > tables are actually allocated > > in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case > > that Xen(hypervisor) needs to > > maintain a page table for each process running in every domain? > > > > Thanks > > > > Haifeng > > > > > > _______________________________________________ > > 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 Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote:> Thanks for answering my question. I am talking about PV mode. What about shadow > page table? Does it mean, Xen will keep (real) copies of page tables?Shadown page tables are employed in HVM guests not PV guests. OV guests still employ p2v m2p mappings. PV guests are aware of the virtualisation. THanks> > Thanks > > Haifeng > > > On Nov 28, 2007 7:10 AM, weiming <zephyr.zhao@gmail.com> wrote: > > In my understanding, in PV, page table is allocated within guest OS, > > however, every update will go through xen via explicit hypercalls. > > in HVM, those update will be intercepted by xen. > > > > Please correct me if I''m wrong. > > > > > > > > On Nov 28, 2007 5:49 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > > > > > > > > > > > Hi, > > > > > > I have a question about memory page tables in Xen. As far as I > > > understood, every modification > > > to page table will go through Xen(hypervisor). Is it so that all page > > > tables are actually allocated > > > in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case > > > that Xen(hypervisor) needs to > > > maintain a page table for each process running in every domain? > > > > > > Thanks > > > > > > Haifeng > > > > > > > > > _______________________________________________ > > > 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 "question = ( to ) ? be : ! be;" -- Wm. Shakespeare _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote:> On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > Thanks for answering my question. I am talking about PV mode. What about shadow > > page table? Does it mean, Xen will keep (real) copies of page tables? > > Shadown page tables are employed in HVM guests not PV guests.regarding shadowed PV domains, there''s still XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore rarely used. regarding the original question: yes, this means xen keeps the real page tables, while guests map pseudo-physical (i.e. linear) memory in what they (may) believe to be the real ones. 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
Hi, At 06:49 +0100 on 29 Nov (1196318951), Daniel Stodden wrote:> On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: > > On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > > Thanks for answering my question. I am talking about PV mode. What about shadow > > > page table? Does it mean, Xen will keep (real) copies of page tables? > > > > Shadown page tables are employed in HVM guests not PV guests.Shadow pagetables are also used when doing live migration of PV guests, but they don''t do the automatic translation and reference-counting that they do for HVM guests.> regarding shadowed PV domains, there''s still > XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore > rarely used.And therefore, AFAIK, doesn''t work. 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
On Nov 28, 2007 4:49 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote:> Hi, > > I have a question about memory page tables in Xen. As far as I > understood, every modification > to page table will go through Xen(hypervisor).that is correct. The hypervisor must know (and validate) all page table updates. Is it so that all page> tables are actually allocated > in Xen(hypervisor) instead of guest OS(domain)?Nope. For page tables, the guest domain has to allocate pages from it''s own memory pool. The guest domain must then inform the hypervisor about these pages so that Xen knows that they are page-table pages.> Also, is it the case > that Xen(hypervisor) needs to > maintain a page table for each process running in every domain?No. Each domain maintains it''s own page tables for processes. The hypervisor only needs to know which physical pages contain page table entries. thanks, satya.> > Thanks > > Haifeng > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Take my advice. I don''t use it anyway. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2007-11-29 at 09:26 +0000, Tim Deegan wrote:> Hi, > > At 06:49 +0100 on 29 Nov (1196318951), Daniel Stodden wrote: > > On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: > > > On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > > > Thanks for answering my question. I am talking about PV mode. What about shadow > > > > page table? Does it mean, Xen will keep (real) copies of page tables? > > > > > > Shadown page tables are employed in HVM guests not PV guests. > > Shadow pagetables are also used when doing live migration of PV guests, > but they don''t do the automatic translation and reference-counting that > they do for HVM guests. > > > regarding shadowed PV domains, there''s still > > XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore > > rarely used. > > And therefore, AFAIK, doesn''t work.Which is why people depending on it are stuck with 3.0.2. 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
Thanks all for the explanation. Haifeng On Nov 29, 2007 9:24 AM, Daniel Stodden <stodden@cs.tum.edu> wrote:> > On Thu, 2007-11-29 at 09:26 +0000, Tim Deegan wrote: > > Hi, > > > > At 06:49 +0100 on 29 Nov (1196318951), Daniel Stodden wrote: > > > On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: > > > > On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > > > > Thanks for answering my question. I am talking about PV mode. What about shadow > > > > > page table? Does it mean, Xen will keep (real) copies of page tables? > > > > > > > > Shadown page tables are employed in HVM guests not PV guests. > > > > Shadow pagetables are also used when doing live migration of PV guests, > > but they don''t do the automatic translation and reference-counting that > > they do for HVM guests. > > > > > regarding shadowed PV domains, there''s still > > > XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore > > > rarely used. > > > > And therefore, AFAIK, doesn''t work. > > Which is why people depending on it are stuck with 3.0.2. > > > 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
> In my understanding, in PV, page table is allocated within guest OS, > however, every update will go through xen via explicit hypercalls. > in HVM, those update will be intercepted by xen.In PV, explicit hypercalls are not always used to update the pagetables. Using the "writeable pagetables" API it''s possible to update the pagetables simply by writing to the pagetable memory (Xen then traps this and does the appropriate validation before applying the update). These days, explicit hypercalls are still used for batching updates for performance reasons (places where trapping lots of writeable pagetable updates would cause a performance hit). Cheers, Mark> Please correct me if I''m wrong. > > On Nov 28, 2007 5:49 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > > Hi, > > > > I have a question about memory page tables in Xen. As far as I > > understood, every modification > > to page table will go through Xen(hypervisor). Is it so that all page > > tables are actually allocated > > in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case > > that Xen(hypervisor) needs to > > maintain a page table for each process running in every domain? > > > > Thanks > > > > Haifeng > > > > _______________________________________________ > > 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
hi I am confused about shadow page table in the paravirtual mode in xen, does guestOS have all of its own processes''page tables,and xen keeps the very exactly all of the guestOS''s processes page tables for a copy? or say ,it is xen who keeps the only copy of the guestOS''s processes page tables ,and guestOS accesses to its processes''s page tables through some hypercall? or ,what about it ? If the guestOS has all of its processes''s page talbes, while xen maintain the copy of all those page tables ,is it an inefficient usage of memory ,or what is the trick behind ? Thanks in advance Daniel Stodden 写道:> On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: > >> On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: >> >>> Thanks for answering my question. I am talking about PV mode. What about shadow >>> page table? Does it mean, Xen will keep (real) copies of page tables? >>> >> Shadown page tables are employed in HVM guests not PV guests. >> > > regarding shadowed PV domains, there''s still > XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore > rarely used. > > regarding the original question: yes, this means xen keeps the real page > tables, while guests map pseudo-physical (i.e. linear) memory in what > they (may) believe to be the real ones. > > regards, > daniel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I am confused about shadow page table in the paravirtual mode in xen, > does guestOS have all of its own processes''page tables,and xen keeps > the very exactly all of the guestOS''s processes page tables for a copy? > or say ,it is xen who keeps the only copy of the guestOS''s processes > page tables ,and guestOS accesses to its processes''s page tables > through some hypercall? or ,what about it ? > If the guestOS has all of its processes''s page talbes, while xen > maintain the copy of all those page tables ,is it an inefficient usage > of memory ,or what is the trick behind ?The process owns all of the pagetables for its processes; Xen does not (in normal operation) maintain a shadow pagetable for PV domains. In PV mode, Xen simply prevents a guest from loading a pagetable for use unless the guest has relinquished all rights to write to that memory. i.e. a guest can only register a pagetable with Xen if there''s no way that the guest can modify that pagetable directly. This guarantees safety. When the guest needs to update the pagetable, it can either write directly to it (which will cause a trap due to lack of permission, then Xen will check whether the update should be allowed) or it can call directly to Xen (which then does safety checks and does the update if it''s OK). Cheers, Mark> Thanks in advance > > Daniel Stodden 写道: > > On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: > >> On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: > >>> Thanks for answering my question. I am talking about PV mode. What > >>> about shadow page table? Does it mean, Xen will keep (real) copies of > >>> page tables? > >> > >> Shadown page tables are employed in HVM guests not PV guests. > > > > regarding shadowed PV domains, there''s still > > XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore > > rarely used. > > > > regarding the original question: yes, this means xen keeps the real page > > tables, while guests map pseudo-physical (i.e. linear) memory in what > > they (may) believe to be the real ones. > > > > regards, > > daniel > > _______________________________________________ > 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
hi I am still confused about the shadow page table in the live migration procession, in this procession, xen shadow page table copy each process''s page table in guestOS ,is it right? what formular is it used ,is it something in the form of page talbe with 3 or 4 levels, or is it just an array like p2m table ,or something? and what does it deal with? if it is only for detecting which page entry is modified ,does it need a whole copy of each process''s page table in xen ,could an extended p2m table be competent? I am not very quite clear about the functions of shadow page talbe in PV mode for live migration ,I have read the live migration paper that during the migration ,WWS should be detected and some mechanism should be used if necessary, but could these be delt with using an extended p2m talbe ,rather than a whole copy of the gurstOS process''s page tables? or there are some tricks behind these obviously inefficient usage of memory, another confusion is the auto_translated_physmap or PV/autotranslated mode , does it also need a whole shadow page table copy in xen? what is form of the page table of this ,are these array or something of 3or 4level page table,and what is the function ? Thanks in advance Mark Williamson 写道:>> I am confused about shadow page table in the paravirtual mode in xen, >> does guestOS have all of its own processes''page tables,and xen keeps >> the very exactly all of the guestOS''s processes page tables for a copy? >> or say ,it is xen who keeps the only copy of the guestOS''s processes >> page tables ,and guestOS accesses to its processes''s page tables >> through some hypercall? or ,what about it ? >> If the guestOS has all of its processes''s page talbes, while xen >> maintain the copy of all those page tables ,is it an inefficient usage >> of memory ,or what is the trick behind ? >> > > > The process owns all of the pagetables for its processes; Xen does not (in > normal operation) maintain a shadow pagetable for PV domains. > > In PV mode, Xen simply prevents a guest from loading a pagetable for use > unless the guest has relinquished all rights to write to that memory. i.e. a > guest can only register a pagetable with Xen if there''s no way that the guest > can modify that pagetable directly. This guarantees safety. > > When the guest needs to update the pagetable, it can either write directly to > it (which will cause a trap due to lack of permission, then Xen will check > whether the update should be allowed) or it can call directly to Xen (which > then does safety checks and does the update if it''s OK). > > Cheers, > Mark > > >> Thanks in advance >> >> Daniel Stodden 写道: >> >>> On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: >>> >>>> On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: >>>> >>>>> Thanks for answering my question. I am talking about PV mode. What >>>>> about shadow page table? Does it mean, Xen will keep (real) copies of >>>>> page tables? >>>>> >>>> Shadown page tables are employed in HVM guests not PV guests. >>>> >>> regarding shadowed PV domains, there''s still >>> XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore >>> rarely used. >>> >>> regarding the original question: yes, this means xen keeps the real page >>> tables, while guests map pseudo-physical (i.e. linear) memory in what >>> they (may) believe to be the real ones. >>> >>> regards, >>> daniel >>> >> _______________________________________________ >> 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
Hi, At 14:39 +0800 on 03 Dec (1196692743), tgh wrote:> hi > I am still confused about the shadow page table in the live migration > procession, > in this procession, xen shadow page table copy each process''s page > table in guestOS ,is it right?Xen makes a set of "shadow" pagetables for the guest to run on, which is based on the guest''s own pagetables. CR3 points at the shadow pagetables. This is the same as for HVM guests, except in HVM Xen needs to translate the entries from GFN to MFNs, and in PV live-migration it only removes write access so that it can track dirtied pages.> what formular is it used ,is it > something in the form of page talbe with 3 or 4 levels, or is it just an > array like p2m table ,or something?It''s a page table. CR3 needs to point at something in the shape of a page table and the guest''s ones won''t do.> and what does it deal with? if it > is only for detecting which page entry is modified ,does it need a whole > copy of each process''s page table in xen ,could an extended p2m table be > competent?No. The p2m is not used by the hardware in PV guests, and can''t be used by the hardware at all (except for HVM guests on the latest AMD chips that support NPT). It''s not a full copy of every page table in the guest, by the way. It''s demand-filled on page-faults and CR3 writes to contain the working set.> I am not very quite clear about the functions of shadow page talbe in > PV mode for live migration ,I have read the live migration paper that > during the migration ,WWS should be detected and some mechanism should > be used if necessary, but could these be delt with using an extended p2m > talbe ,rather than a whole copy of the gurstOS process''s page tables? or > there are some tricks behind these obviously inefficient usage of memory,The memory use is not all that bad. The main drawback of shadow pagetables is the latency of previously simple operations like page faults.> another confusion is the auto_translated_physmap or PV/autotranslated > mode , does it also need a whole shadow page table copy in xen? what > is form of the page table of this ,are these array or something of 3or > 4level page table,and what is the function ?Auto-translated PV shadow mode uses all the same code for making shadow pagetables as every other mode; it just includes a translation from GFN to MFN when making the shadow PTEs. Cheers, 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
hi in the PV mode,VM guestOS pagetable is virtual-to-machine address mapping,is it right?,and when a VM is migrated, the shadow page table mode will be enabled ,is it right? then, the PVguestOS pagetalbe will become the virtual-to-psuedophysical address mapping, or not? then ,at that time ,the shadow pagetalbe is virtual-to-machine one ,is it right? I am still confused ,especially about the PVguestOS pagetalbe when shadow pagetable enabled for migration? is it a virtual-to-machine address mapping, or a virtual-to-psuedophysical address one ? Thanks in advance Mark Williamson 写道:>> I am confused about shadow page table in the paravirtual mode in xen, >> does guestOS have all of its own processes''page tables,and xen keeps >> the very exactly all of the guestOS''s processes page tables for a copy? >> or say ,it is xen who keeps the only copy of the guestOS''s processes >> page tables ,and guestOS accesses to its processes''s page tables >> through some hypercall? or ,what about it ? >> If the guestOS has all of its processes''s page talbes, while xen >> maintain the copy of all those page tables ,is it an inefficient usage >> of memory ,or what is the trick behind ? >> > > > The process owns all of the pagetables for its processes; Xen does not (in > normal operation) maintain a shadow pagetable for PV domains. > > In PV mode, Xen simply prevents a guest from loading a pagetable for use > unless the guest has relinquished all rights to write to that memory. i.e. a > guest can only register a pagetable with Xen if there''s no way that the guest > can modify that pagetable directly. This guarantees safety. > > When the guest needs to update the pagetable, it can either write directly to > it (which will cause a trap due to lack of permission, then Xen will check > whether the update should be allowed) or it can call directly to Xen (which > then does safety checks and does the update if it''s OK). > > Cheers, > Mark > > >> Thanks in advance >> >> Daniel Stodden 写道: >> >>> On Thu, 2007-11-29 at 11:00 +0530, pradeep singh rautela wrote: >>> >>>> On Nov 29, 2007 1:42 AM, Haifeng He <hehaifeng2nd@gmail.com> wrote: >>>> >>>>> Thanks for answering my question. I am talking about PV mode. What >>>>> about shadow page table? Does it mean, Xen will keep (real) copies of >>>>> page tables? >>>>> >>>> Shadown page tables are employed in HVM guests not PV guests. >>>> >>> regarding shadowed PV domains, there''s still >>> XENFEAT_auto_translated_physmap. but it''s rather exotic and therefore >>> rarely used. >>> >>> regarding the original question: yes, this means xen keeps the real page >>> tables, while guests map pseudo-physical (i.e. linear) memory in what >>> they (may) believe to be the real ones. >>> >>> regards, >>> daniel >>> >> _______________________________________________ >> 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
At 20:12 +0800 on 05 Dec (1196885526), tgh wrote:> hi > in the PV mode,VM guestOS pagetable is virtual-to-machine address > mapping,is it right?Yes.>,and when a VM is migrated, the shadow page table > mode will be enabled ,is it right?Yes.> then, the PVguestOS pagetalbe will > become the virtual-to-psuedophysical address mapping, or not?Not.> then ,at > that time ,the shadow pagetalbe is virtual-to-machine one ,is it right?Yes.> I am still confused ,especially about the PVguestOS pagetalbe when > shadow pagetable enabled for migration? is it a virtual-to-machine > address mapping, or a virtual-to-psuedophysical address one ?*All* shadow pagetables are virtual-to-machine translations. Anything else wouldn''t be much use. Cheers, 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
hi in the PV mode, when VM is migrated, the shadow page table will be created , that is ,the every active process pagetable in the guestOS will have a copy in the VMM, while the original one is maintianed as virtual-to-physical address mapping , is it right? then, when the guestOS process is scheduled , the shadow page table will be set into the CR3 and the CPU address mapping will be worked with the shadow pagetable rather than the original one, is it right? while every update to the process original pagetable in the guestOS will be trap into the VMM , where the shadow pagetable is updated and coherented with the original one, is it right? Thanks in advance Tim Deegan 写道:> At 20:12 +0800 on 05 Dec (1196885526), tgh wrote: > >> hi >> in the PV mode,VM guestOS pagetable is virtual-to-machine address >> mapping,is it right? >> > > Yes. > > >> ,and when a VM is migrated, the shadow page table >> mode will be enabled ,is it right? >> > > Yes. > > >> then, the PVguestOS pagetalbe will >> become the virtual-to-psuedophysical address mapping, or not? >> > > Not. > > >> then ,at >> that time ,the shadow pagetalbe is virtual-to-machine one ,is it right? >> > > Yes. > > >> I am still confused ,especially about the PVguestOS pagetalbe when >> shadow pagetable enabled for migration? is it a virtual-to-machine >> address mapping, or a virtual-to-psuedophysical address one ? >> > > *All* shadow pagetables are virtual-to-machine translations. Anything > else wouldn''t be much use. > > Cheers, > > Tim. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 20:47 +0800 on 05 Dec (1196887651), tgh wrote:> hi > in the PV mode, when VM is migrated, the shadow page table will be > created , that is ,the every active process pagetable in the guestOS > will have a copy in the VMM, while the original one is maintianed as > virtual-to-physical address mapping , is it right?Yes, though as I said we only shadow pagetables on demand when they are used.> then, when the > guestOS process is scheduled , the shadow page table will be set into > the CR3 and the CPU address mapping will be worked with the shadow > pagetable rather than the original one, is it right?Yes.> while every update > to the process original pagetable in the guestOS will be trap into the > VMM , where the shadow pagetable is updated and coherented with the > original one, is it right?Yes. Why are you asking this, by the way? Are you trying to write code, or debug a problem, or write documentation? 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
Thank you for explanation I have read the code ,and want to comfirm some confusion,and then try to write something new,if nessary the shadow pagetable on demand ,means a whole pagetable copy when the process is scheduled, or just a part of the process''s pagetable is copied thanks in advance cheers Tim Deegan 写道:> At 20:47 +0800 on 05 Dec (1196887651), tgh wrote: > >> hi >> in the PV mode, when VM is migrated, the shadow page table will be >> created , that is ,the every active process pagetable in the guestOS >> will have a copy in the VMM, while the original one is maintianed as >> virtual-to-physical address mapping , is it right? >> > > Yes, though as I said we only shadow pagetables on demand when they are used. > > >> then, when the >> guestOS process is scheduled , the shadow page table will be set into >> the CR3 and the CPU address mapping will be worked with the shadow >> pagetable rather than the original one, is it right? >> > > Yes. > > >> while every update >> to the process original pagetable in the guestOS will be trap into the >> VMM , where the shadow pagetable is updated and coherented with the >> original one, is it right? >> > > Yes. > > Why are you asking this, by the way? Are you trying to write code, > or debug a problem, or write documentation? > > Tim. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 09:03 +0800 on 06 Dec (1196931839), tgh wrote:> I have read the code ,and want to comfirm some confusion,and then try to > write something new,if nessaryWhat do you want to write?> the shadow pagetable on demand ,means a whole pagetable copy when the > process is scheduled, or just a part of the process''s pagetable is copiedPagetable pages are shadowed in shadow_get_and_create_*, called from sh_page_fault(), and in sh_update_cr3(), all in arch/x86/mm/shadow/multi.c. 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
Possibly Parallel Threads
- [LLVMdev] Compile Linux Kernel with LLVM gcc frontend
- [LLVMdev] Problem of running data structure analysis (DSA) on Linux kernel
- page table question!
- [LLVMdev] Compile Linux Kernel with LLVM gcc frontend
- [LLVMdev] Problem of running data structure analysis (DSA) on Linux kernel