Re: [Xen-ia64-devel] Question about migration

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Fri, Feb 01, 2008 at 04:01:04PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Fri, Feb 01, 2008 at 03:08:24PM +0800, Xu, Anthony wrote:
> >> In DomU, ar.itc is not virtualized, so application can get itc
> >> directly. When DomU is migrated, how do you prevent vitc jump a lot(
> >> foreward/backward)?
> > 
> > Currently nothing prevents it. So a big itc jump can happen.
> > Anyway user application can be stopped/continued by SIGSTOP/SIGCONT
> > so that user application should be tolerable with such a big jump of
> > itc. 
> Foreward jump may be OK,
> How about back-ward jump? Application may be confused.
> 
> > 
> > So in theory it's ok. But I'm not sure in practical.
> > Do you have any concrete examples/scenario in your mind?
> No, But I know some DB use ITC,

I see. So ITC is used for some kind of sequence counter.
I remembered that the timer interpolator in the Linux kernel was
confused so that kernel timer wasn't fired after restore.
I fixed it just by clearing its internal state when restored but
applications can't be modified.

Hmmm, so itc should be virtualizsed for such applications? (at least
for ring 3)
Another question brings up in my mind: what if suspend/resume even
on native.
More strictly what does kernel gurantee with regard to ITC to user
process? I.e. what can applications assume with ITC?
Kenrel is allowed to change ITC.
However SDM vol.1 3.1.8.10 says that 
> A sequence of reads of the ITC is guaranteed to return ever-increasing
> values (except for the case
> of the counter wrapping back to 0) corresponding to the program order
> of the reads. Applications
> can directly sample the ITC for time-based calculations.
-- 
yamahata

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