| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] First migration ! and RFCs...
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
|
|
|
| |
|
Home