WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] First migration ! and RFCs...

Le Jeudi 06 Juillet 2006 06:34, Isaku Yamahata a écrit :
> On Wed, Jul 05, 2006 at 05:14:48PM +0200, Tristan Gingold wrote:
[...]
> > * When a dirty bit fault occurs Xen has to re-insert the pte.  This
> > requires more information than available directly in the handler but
> > these informations should be available in the VHPT.  However if the VHPT
> > entry doesn't match, a page fault has to be injected which may be
> > inefficient or prevent forward progress...
> >
> > * Where is the bitmap ?  Within the data dirty fault, the virtual address
> > is available but useless.  The physical address is available.  Because it
> > is too sparse (like the memmap) the natural way is to put the bit within
> > the memmap. Or we can add a gpfn index within the VHPT and using a
> > compact bitmap.
> >
> > Thoughts ?
>
> I suppose you meant 'the physicall address' = 'machine address'
>                                               (not phsudo physical address)
Yes.

> This is just a idea.
> There is the m2p table. get_gpfn_from_mfn() gives gpfn from mfn.
> I'm not sure that the m2p table is really needed for now though.
> Then the d bit of the p2m table entry can be expoited.
> The bit isn't well used now. Pros: page flipping
> (i.e. exchanging the p2m entry) can automatically set its d bit.
You are proposing m2p while Kevin suggested p2m!  I have to look closer.
Page flipping handling is a good point not to be missed.

Thanks,
Tristan.

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