[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-ia64-devel] First migration ! and RFCs...
On Wed, Jul 05, 2006 at 05:14:48PM +0200, Tristan Gingold wrote:
> I have just successfully migrated a domU from a tiger 4 (Montecito) to a
> tiger 2 (Madison).
> 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.
Xen-ia64-devel mailing list