On 25/04/16 12:18, Stefano Stabellini wrote: > From: Jan Beulich <jbeul...@suse.com> > > For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time() > using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct > vcpu_time_info, is calculated from stime_local_stamp using > gtime_to_gtsc. > > However gtime_to_gtsc can return 0, if time < vtsc_offset, which can > actually happen when gtime_to_gtsc is called passing stime_local_stamp > (the caller function is __update_vcpu_system_time). > > In that case the pvclock protocol doesn't work properly and the guest is > unable to calculate the system time correctly. As a consequence when the > guest tries to set a timer event (for example calling the > VCPUOP_set_singleshot_timer hypercall), the event will be in the past > causing Linux to hang. > > The purpose of the pvclock protocol is to allow the guest to calculate > the system_time in nanosec correctly. The guest calculates as follow: > > from_vtsc_scale(rdtsc - vcpu_time_info.tsc_timestamp) + > vcpu_time_info.system_time > > Given that with vtsc=1: > rdtsc = to_vtsc_scale(NOW() - vtsc_offset) > vcpu_time_info.tsc_timestamp = to_vtsc_scale(vcpu_time_info.system_time - > vtsc_offset) > > The expression evaluates to NOW(), which is what we want. However when > stime_local_stamp < vtsc_offset, vcpu_time_info.tsc_timestamp is > actually 0. As a consequence the calculated overall system_time is not > correct. > > This patch fixes the issue by letting gtime_to_gtsc return a negative > integer in the form of a wrapped around unsigned integer, thus when the > guest subtracts vcpu_time_info.tsc_timestamp from rdtsc will calculate > the right value. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel