search for: vclock_hvclock

Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the required support re-using pvclock_page VVAR as VCLOCK_PVCLOCK is mutually exclusive with VCLOCK_HVCLOCK at run time. Signed-off-by: Vitaly Kuznetsov <vkuznets at redhat.com> --- arch/x86/entry/vdso/vclock_gettime.c | 48 ++++++++++++++++++++++++++++++++++++ arch/x86/entry/vdso/vma.c | 26 +++++++++++++------ arch/x86/hyperv/hv_init.c | 3 +++ arch/x86/include/asm/clocks...

...VCLOCK_NONE; + return 0; +} +#endif notrace static u64 vread_tsc(void) { @@ -173,6 +205,10 @@ notrace static inline u64 vgetsns(int *mode) else if (gtod->vclock_mode == VCLOCK_PVCLOCK) cycles = vread_pvclock(mode); #endif +#ifdef CONFIG_HYPERV_TSCPAGE + else if (gtod->vclock_mode == VCLOCK_HVCLOCK) + cycles = vread_hvclock(mode); +#endif else return 0; v = (cycles - gtod->cycle_last) & gtod->mask; diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S b/arch/x86/entry/vdso/vdso-layout.lds.S index a708aa9..8ebb4b6 100644 --- a/arch/x86/entry/vdso/vdso-layout.lds.S +++ b/arch/x86...

...etsov <vkuznets at redhat.com> wrote: > Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol > defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the > required support re-using pvclock_page VVAR as VCLOCK_PVCLOCK is mutually > exclusive with VCLOCK_HVCLOCK at run time. > > Signed-off-by: Vitaly Kuznetsov <vkuznets at redhat.com> > --- > arch/x86/entry/vdso/vclock_gettime.c | 48 ++++++++++++++++++++++++++++++++++++ > arch/x86/entry/vdso/vma.c | 26 +++++++++++++------ > arch/x86/hyperv/hv_init.c | 3 +++...

...etsov <vkuznets at redhat.com> wrote: > Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol > defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the > required support re-using pvclock_page VVAR as VCLOCK_PVCLOCK is mutually > exclusive with VCLOCK_HVCLOCK at run time. > > Signed-off-by: Vitaly Kuznetsov <vkuznets at redhat.com> > --- > arch/x86/entry/vdso/vclock_gettime.c | 48 ++++++++++++++++++++++++++++++++++++ > arch/x86/entry/vdso/vma.c | 26 +++++++++++++------ > arch/x86/hyperv/hv_init.c | 3 +++...

...lt;haiyangz at microsoft.com>; Stephen > Hemminger <sthemmin at microsoft.com>; Dexuan Cui > <decui at microsoft.com>; linux-kernel at vger.kernel.org; > devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org > Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read > method > > On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: > > +#ifdef CONFIG_HYPERV_TSCPAGE > > +static notrace u64 vread_hvclock(int *mode) > > +{ > > + const struct ms_hyperv_tsc_page *tsc_pg = > > + (const struct ms_hyperv_tsc_page *)&h...

...gt;; Haiyang Zhang <haiyangz at microsoft.com>; Stephen Hemminger <sthemmin at microsoft.com>; Dexuan Cui <decui at microsoft.com>; linux-kernel at vger.kernel.org; devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: > +#ifdef CONFIG_HYPERV_TSCPAGE > +static notrace u64 vread_hvclock(int *mode) { > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&hvclock_page; > + u64 sequence, scale, offse...

Stephen Hemminger <sthemmin at microsoft.com> writes: > Why not use existing seqlock's? > To be honest I don't quite understand how we could use it -- the sequence locking here is done against the page updated by the hypersior, we're not creating new structures (so I don't understand how we could use struct seqcount which we don't have) but I may be

Stephen Hemminger <sthemmin at microsoft.com> writes: > Why not use existing seqlock's? > To be honest I don't quite understand how we could use it -- the sequence locking here is done against the page updated by the hypersior, we're not creating new structures (so I don't understand how we could use struct seqcount which we don't have) but I may be

...ytor.com>; KY Srinivasan <kys at microsoft.com>; Haiyang Zhang <haiyangz at microsoft.com>; Dexuan Cui <decui at microsoft.com>; linux-kernel at vger.kernel.org; devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method On Fri, 10 Feb 2017, Vitaly Kuznetsov wrote: > Stephen Hemminger <sthemmin at microsoft.com> writes: > > > Why not use existing seqlock's? > > > > To be honest I don't quite understand how we could use it -- the > sequence locking...

...ytor.com>; KY Srinivasan <kys at microsoft.com>; Haiyang Zhang <haiyangz at microsoft.com>; Dexuan Cui <decui at microsoft.com>; linux-kernel at vger.kernel.org; devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method On Fri, 10 Feb 2017, Vitaly Kuznetsov wrote: > Stephen Hemminger <sthemmin at microsoft.com> writes: > > > Why not use existing seqlock's? > > > > To be honest I don't quite understand how we could use it -- the > sequence locking...

...icrosoft.com>; Stephen >> Hemminger <sthemmin at microsoft.com>; Dexuan Cui >> <decui at microsoft.com>; linux-kernel at vger.kernel.org; >> devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org >> Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read >> method >> >> On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: >> > +#ifdef CONFIG_HYPERV_TSCPAGE >> > +static notrace u64 vread_hvclock(int *mode) >> > +{ >> > + const struct ms_hyperv_tsc_page *tsc_pg = >> > +...

...icrosoft.com>; Stephen >> Hemminger <sthemmin at microsoft.com>; Dexuan Cui >> <decui at microsoft.com>; linux-kernel at vger.kernel.org; >> devel at linuxdriverproject.org; virtualization at lists.linux-foundation.org >> Subject: Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read >> method >> >> On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: >> > +#ifdef CONFIG_HYPERV_TSCPAGE >> > +static notrace u64 vread_hvclock(int *mode) >> > +{ >> > + const struct ms_hyperv_tsc_page *tsc_pg = >> > +...

Thomas Gleixner <tglx at linutronix.de> writes: > On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: >> +#ifdef CONFIG_HYPERV_TSCPAGE >> +static notrace u64 vread_hvclock(int *mode) >> +{ >> + const struct ms_hyperv_tsc_page *tsc_pg = >> + (const struct ms_hyperv_tsc_page *)&hvclock_page; >> + u64 sequence, scale, offset, current_tick, cur_tsc; >>

On Fri, 10 Feb 2017, Vitaly Kuznetsov wrote: > Stephen Hemminger <sthemmin at microsoft.com> writes: > > > Why not use existing seqlock's? > > > > To be honest I don't quite understand how we could use it -- the > sequence locking here is done against the page updated by the > hypersior, we're not creating new structures (so I don't understand

On Fri, 10 Feb 2017, Stephen Hemminger wrote: > Since sequence count algorithm is done by hypervisor, better to not reuse seqcount. > Still concerned that the code is racy. That's a different question and can only be answered by the hypervisor folks. Dunno, whether they have barrier requirements. The seqcount stuff relies on: do { seq = READ_ONCE(s->sequence); smp_rmb();

On Sun, Feb 12, 2017 at 11:49 PM, Dexuan Cui <decui at microsoft.com> wrote: >> From: Thomas Gleixner [mailto:tglx at linutronix.de] >> Sent: Saturday, February 11, 2017 02:02 >> ... >> That's important if the stuff happens cross CPU. If the update happens on >> the same CPU then this is a different story and as there are VMexits >> involved they

...eal 1m22.618s user 0m50.193s sys 0m32.268s After: # time sysbench --test=memory --max-requests=500000 run ... real 0m50.218s user 0m50.171s sys 0m0.016s So it seems it is worth it. What do you think? Vitaly Kuznetsov (2): hyperv: implement hv_get_tsc_page() x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method arch/x86/entry/vdso/vclock_gettime.c | 48 ++++++++++++++++++++++++++++++++++++ arch/x86/entry/vdso/vma.c | 26 +++++++++++++------ arch/x86/hyperv/hv_init.c | 8 ++++++ arch/x86/include/asm/clocksource.h | 3 ++- arch/x86/include/asm/mshyperv.h...

...eal 1m22.618s user 0m50.193s sys 0m32.268s After: # time sysbench --test=memory --max-requests=500000 run ... real 0m50.218s user 0m50.171s sys 0m0.016s So it seems it is worth it. What do you think? Vitaly Kuznetsov (2): hyperv: implement hv_get_tsc_page() x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method arch/x86/entry/vdso/vclock_gettime.c | 48 ++++++++++++++++++++++++++++++++++++ arch/x86/entry/vdso/vma.c | 26 +++++++++++++------ arch/x86/hyperv/hv_init.c | 8 ++++++ arch/x86/include/asm/clocksource.h | 3 ++- arch/x86/include/asm/mshyperv.h...

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tell > as I have no idea how that host side

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tell > as I have no idea how that host side