[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.