WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Subject: Re: [Xen-ia64-devel] First migration ! and RFCs...
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Thu, 6 Jul 2006 13:34:52 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 05 Jul 2006 21:35:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200607051714.48150.Tristan.Gingold@xxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200607051714.48150.Tristan.Gingold@xxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i

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