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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Tristan Gingold
>Sent: 2006年7月5日 23:15
>
>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...

If current logic always ensures VHPT is the superset of machine DTLB, 
ideally the entry can be always hit from VHPT once dirty bit fault occurs. 
Or else you have to inject...

Psr.da also requires virtualized in this context.

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

Memmap is xen wise and you need extra check for domain ownership 
when retrieving information. VHPT table is only a cache to guest vTLB 
activity which doesn't contain all the dirty entries in the migration period.
So how about creating the bit in p2m table which is domain specific 
only?  the p2m table can be mapped to the virtual address space of 
migration thread which can then monitor the dirty status convergent in 
the migration process.

Thanks,
Kevin

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