|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|