Re: [Xen-devel] [PATCH] x86/time: update TSC stamp on restore from deep C-state

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Jan 16, 2020 at 12:09:12PM +0000, Igor Druzhinin wrote:
> On 16/01/2020 09:38, Jan Beulich wrote:
> > On 16.01.2020 10:33, Roger Pau Monné wrote:
> >> On Wed, Jan 15, 2020 at 05:21:16PM +0100, Jan Beulich wrote:
> >>> On 15.01.2020 14:44, Roger Pau Monné wrote:
> >>>> On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
> >>>>> What I'm then worried about is too
> >>>>> little progress observable by guests. The PV time protocol
> >>>>> ought to be fine in this regard (and consumers of raw TSC values
> >>>>> are on their own anyway), but wouldn't you need to update TSC
> >>>>> offsets of HVM guests in order to compensate for the elapsed
> >>>>> time?
> >>>>
> >>>> That will be done when the HVM vCPU gets scheduled in as part of the
> >>>> update_vcpu_system_time call AFAICT. cstate_restore_tsc will always be
> >>>> called with the idle vCPU context, and hence there's always going to
> >>>> be a vCPU switch before scheduling anything else.
> >>>
> >>> Which step would this be? All I see is a call to hvm_scale_tsc().
> >>> In time.c only tsc_set_info() calls hvm_set_tsc_offset().
> >>
> >> My bad, I've mistaken the scaling with the offset.
> >>
> >> Accounting for the offset in update_vcpu_system_time seems quite
> >> more complicated that just updating the TSC here, so:
> >>
> >> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > 
> > And then (preferably with "deep" dropped from the description,
> > if you, Igor, agree, and which can be done while committing)
> > Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> No objection. FYI I tested Roger's approach this night and it seems
> to work at least in sense of fixing the original issue.

Right, but HVM guests using a timekeeping approach similar to what Xen
does (read the platform timer periodically and calculate time based on
the last read plus the TSC delta) would get wrong (behind the real
time) results AFAICT.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel