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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 06 Juillet 2006 05:20, Tian, Kevin a écrit :
> 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.
Unless the VHPT entry was replaced but not the itc entry.
I don't know wether this scenario can happen frequently or not.

Also if we want to handle page smaller than the VHPT page size, the 
translations may only be in the TLB cache but not in the VHPT.  This is a 
possible issue for the future.

> Or else you have to inject...
Sure.

> Psr.da also requires virtualized in this context.
Right.

> >* 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.
I don't think this is a real issue.  As far as I understand, on x86 the bitmap 
is copied to user space.

> VHPT table is only a cache to guest vTLB
> activity which doesn't contain all the dirty entries in the migration
> period.
Correct.

> 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.
Seems to be a good idea.

I'd like to handle the dirty bit in the handler, without calling C code.  I 
don't know if this is really a good idea but the first consequence is nested 
miss must be handled.

Thank you for the ideas,
Tristan.

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