Re: [Xen-devel] Page tables in Xen

[tgh <wwwwww4187@xxxxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >     
>
>
>   

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