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/
Home Products Support Community News


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

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

Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>