lkml.org 
[lkml]   [2017]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/3] KVM: x86: provide realtime host clock via vsyscall notifiers
On Fri, Jan 13, 2017 at 10:41:10AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote:
> > 2017-01-13 10:01-0200, Marcelo Tosatti:
> > > Expose the realtime host clock and save the TSC value
> > > used for the clock calculation.
> > >
> > > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> > >
> > > ---
> > > arch/x86/kvm/x86.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 38 insertions(+)
> > >
> > > Index: kvm-ptpdriver/arch/x86/kvm/x86.c
> > > ===================================================================
> > > --- kvm-ptpdriver.orig/arch/x86/kvm/x86.c 2017-01-13 08:59:03.015895353 -0200
> > > +++ kvm-ptpdriver/arch/x86/kvm/x86.c 2017-01-13 09:04:46.581415259 -0200
> > > @@ -1139,6 +1139,8 @@
> > >
> > > u64 boot_ns;
> > > u64 nsec_base;
> > > + u64 wall_time_sec;
> > > + u64 wall_time_snsec;
> >
> > The leading "s" in "snsec" looks like a copy-paste residue.
> >
> > > };
> > >
> > > static struct pvclock_gtod_data pvclock_gtod_data;
> > > @@ -1162,6 +1164,9 @@
> > > vdata->boot_ns = boot_ns;
> > > vdata->nsec_base = tk->tkr_mono.xtime_nsec;
> > >
> > > + vdata->wall_time_sec = tk->xtime_sec;
> > > + vdata->wall_time_snsec = tk->tkr_mono.xtime_nsec;
> >
> > Using tk->tkr_mono offsets for real time seems wrong -- what happens if
> > the real time is half a second shifted from monotonic time?
> >
> > If it's ok, then vdata->nsec_base == vdata->wall_time_snsec, so we don't
> > need it.
> >
> > > +
> > > write_seqcount_end(&vdata->seq);
> > > }
> > > #endif
> > > @@ -1623,6 +1628,28 @@
> > > return mode;
> > > }
> > >
> > > +static int do_realtime(struct timespec *ts, cycle_t *cycle_now)
> >
> > This is too similar to do_monotonic_boot(), but I don't see a solution
> > that is both nice and efficient. :(
> >
> > (It usually means macros or copying pvclock_gtod_data.)
>
>
> PV Clock is hypervisor agnostic so both KVM and Xen can use it. Is this clock
> interface suppose to follow that?

If Xen implements the KVM_HC_CLOCK_OFFSET hypercall, Xen guests can use the
kvm ptp driver, yes.


\
 
 \ /
  Last update: 2017-01-13 17:00    [W:0.142 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site