Re: [Xen-devel] Could you please answer some questions regarding Solaris PVHVM pvclock support.

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 26 Feb 2014, Qin Li wrote:
> 
> ä 2014/1/16 20:17, Stefano Stabellini åé:
> 
> . For a PV-on-HVM guest OS, the "shared_info->vcpu_info->vcpu_time_info"
> > is already visiable. Does guest OS still need any action to ask
> > hypervisor to update this piece of memory periodically?
> 
> I don't think you need to ask the hypervisor to update vcpu_time_info
> periodically, what gave you that idea?
> 
> Hi Stefano,
> 
> Now, I see it's the hypervisor that will update vcpu_time_info, but another 
> thing confuse me:
> HVM guest has time drift issue because TSC on different vCPU could be 
> out-of-sync, especially after domain suspend/resume.
> But how pvclock actually fix this issue? Let's see how FreeBSD port calculate 
> the system time:
> 
> ==================
> static uint64_t
> get_nsec_offset(struct vcpu_time_info *tinfo)
> {
> 
> ÂÂÂ return (scale_delta(rdtsc() - tinfo->tsc_timestamp,
> ÂÂÂ ÂÂÂ tinfo->tsc_to_system_mul, tinfo->tsc_shift));
> }
> 
> /**
> Â* \brief Get the current time, in nanoseconds, since the hypervisor booted.
> Â*
> Â* \note This function returns the current CPU's idea of this value, unless
> Â*ÂÂÂÂÂÂ it happens to be less than another CPU's previously determined value.
> Â*/
> static uint64_t
> xen_fetch_vcpu_time(void)
> {
> ÂÂÂ struct vcpu_time_info dst;
> ÂÂÂ struct vcpu_time_info *src;
> ÂÂÂ uint32_t pre_version;
> ÂÂÂ uint64_t now;
> ÂÂÂ volatile uint64_t last;
> ÂÂÂ struct vcpu_info *vcpu = DPCPU_GET(vcpu_info);
> 
> ÂÂÂ src = &vcpu->time;
> 
> ÂÂÂ critical_enter();
> ÂÂÂ do {
> ÂÂÂ ÂÂÂ pre_version = xen_fetch_vcpu_tinfo(&dst, src);
> ÂÂÂ ÂÂÂ barrier();
> ÂÂÂ ÂÂÂ now = dst.system_time + get_nsec_offset(&dst);
> ÂÂÂ ÂÂÂ barrier();
> ÂÂÂ } while (pre_version != src->version);
> 
> ÂÂÂ /*
> ÂÂÂ Â* Enforce a monotonically increasing clock time across all
>  Â* VCPUs. If our time is too old, use the last time and return.
> ÂÂÂ Â* Otherwise, try to update the last time.
> ÂÂÂ Â*/
> ÂÂÂ do {
> ÂÂÂ ÂÂÂ last = last_time;
> ÂÂÂ ÂÂÂ if (last > now) {
> ÂÂÂ ÂÂÂ ÂÂÂ now = last;
> ÂÂÂ ÂÂÂ ÂÂÂ break;
> ÂÂÂ ÂÂÂ }
> ÂÂÂ } while (!atomic_cmpset_64(&last_time, last, now));
> 
> ÂÂÂ critical_exit();
> 
> ÂÂÂ return (now);
> }
> ==================================
> 
> I guest linux guest will do the same thing, rdtsc() fetch current timestamp 
> from current running vCPU, TSC out-of-sync issue is still there.
> It seems to me pvclock finally fix the time drift issue just because the 
> workaround enforced as above, right?

First you should know that TSC is not always guaranteed to be
synchronized across multiple processors, especially on older systems.
On "TSC-safe" systems, Xen would export a consistent TSC to guests, by
setting the vtsc offset and scale appropriately.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel