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

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Wed, Jul 05, 2006 at 05:14:48PM +0200, Tristan Gingold wrote:
> Hi,
> 
> I have just successfully migrated a domU from a tiger 4  (Montecito) to a 
> tiger 2 (Madison).

very nice!


> This was of course a non-live migration.
> 
> I will start to work on live migration.
> 
> The live migration requires a bitmap of dirtied pages.  So the d bit (dirty 
> bit) has to be virtualized.
> 
> I can see at least two issues now:
> 
> * 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)

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.

-- 
yamahata

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