<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/clocksource/hyperv_timer.c, branch v5.10-rc6</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>hv: clocksource: Add notrace attribute to read_hv_sched_clock_*() functions</title>
<updated>2020-09-28T09:04:48+00:00</updated>
<author>
<name>Mohammed Gamal</name>
<email>mgamal@redhat.com</email>
</author>
<published>2020-09-24T15:11:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1f3aed01473c41c9f896fbf4c30d330655e8aa7c'/>
<id>1f3aed01473c41c9f896fbf4c30d330655e8aa7c</id>
<content type='text'>
When selecting function_graph tracer with the command:
 # echo function_graph &gt; /sys/kernel/debug/tracing/current_tracer

The kernel crashes with the following stack trace:

[69703.122389] BUG: stack guard page was hit at 000000001056545c (stack is 00000000fa3f8fed..0000000005d39503)
[69703.122403] kernel stack overflow (double-fault): 0000 [#1] SMP PTI
[69703.122413] CPU: 0 PID: 16982 Comm: bash Kdump: loaded Not tainted 4.18.0-236.el8.x86_64 #1
[69703.122420] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[69703.122433] RIP: 0010repare_ftrace_return+0xa/0x110
[69703.122458] Code: 05 00 0f 0b 48 c7 c7 10 ca 69 ae 0f b6 f0 e8 4b 52 0c 00 31 c0 eb ca 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 41 54 &lt;53&gt; 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 85
[69703.122467] RSP: 0018:ffffbd6d01118000 EFLAGS: 00010086
[69703.122476] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000003
[69703.122484] RDX: 0000000000000000 RSI: ffffbd6d011180d8 RDI: ffffffffadce7550
[69703.122491] RBP: ffffbd6d01118018 R08: 0000000000000000 R09: ffff9d4b09266000
[69703.122498] R10: ffff9d4b0fc04540 R11: ffff9d4b0fc20a00 R12: ffff9d4b6e42aa90
[69703.122506] R13: ffff9d4b0fc20ab8 R14: 00000000000003e8 R15: ffffbd6d0111837c
[69703.122514] FS:  00007fd5f2588740(0000) GS:ffff9d4b6e400000(0000) knlGS:0000000000000000
[69703.122521] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[69703.122528] CR2: ffffbd6d01117ff8 CR3: 00000000565d8001 CR4: 00000000003606f0
[69703.122538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[69703.122545] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[69703.122552] Call Trace:
[69703.122568]  ftrace_graph_caller+0x6b/0xa0
[69703.122589]  ? read_hv_sched_clock_tsc+0x5/0x20
[69703.122599]  read_hv_sched_clock_tsc+0x5/0x20
[69703.122611]  sched_clock+0x5/0x10
[69703.122621]  sched_clock_local+0x12/0x80
[69703.122631]  sched_clock_cpu+0x8c/0xb0
[69703.122644]  trace_clock_global+0x21/0x90
[69703.122655]  ring_buffer_lock_reserve+0x100/0x3c0
[69703.122671]  trace_buffer_lock_reserve+0x16/0x50
[69703.122683]  __trace_graph_entry+0x28/0x90
[69703.122695]  trace_graph_entry+0xfd/0x1a0
[69703.122705]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122714]  ? sched_clock+0x5/0x10
[69703.122723]  prepare_ftrace_return+0x99/0x110
[69703.122734]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122743]  ? sched_clock+0x5/0x10
[69703.122752]  ftrace_graph_caller+0x6b/0xa0
[69703.122768]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122777]  ? sched_clock+0x5/0x10
[69703.122786]  ? read_hv_sched_clock_tsc+0x5/0x20
[69703.122796]  ? ring_buffer_unlock_commit+0x1d/0xa0
[69703.122805]  read_hv_sched_clock_tsc+0x5/0x20
[69703.122814]  ftrace_graph_caller+0xa0/0xa0
[ ... recursion snipped ... ]

Setting the notrace attribute for read_hv_sched_clock_msr() and
read_hv_sched_clock_tsc() fixes it.

Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function")
Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Mohammed Gamal &lt;mgamal@redhat.com&gt;
Link: https://lore.kernel.org/r/20200924151117.767442-1-mgamal@redhat.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When selecting function_graph tracer with the command:
 # echo function_graph &gt; /sys/kernel/debug/tracing/current_tracer

The kernel crashes with the following stack trace:

[69703.122389] BUG: stack guard page was hit at 000000001056545c (stack is 00000000fa3f8fed..0000000005d39503)
[69703.122403] kernel stack overflow (double-fault): 0000 [#1] SMP PTI
[69703.122413] CPU: 0 PID: 16982 Comm: bash Kdump: loaded Not tainted 4.18.0-236.el8.x86_64 #1
[69703.122420] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[69703.122433] RIP: 0010repare_ftrace_return+0xa/0x110
[69703.122458] Code: 05 00 0f 0b 48 c7 c7 10 ca 69 ae 0f b6 f0 e8 4b 52 0c 00 31 c0 eb ca 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 41 54 &lt;53&gt; 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 85
[69703.122467] RSP: 0018:ffffbd6d01118000 EFLAGS: 00010086
[69703.122476] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000003
[69703.122484] RDX: 0000000000000000 RSI: ffffbd6d011180d8 RDI: ffffffffadce7550
[69703.122491] RBP: ffffbd6d01118018 R08: 0000000000000000 R09: ffff9d4b09266000
[69703.122498] R10: ffff9d4b0fc04540 R11: ffff9d4b0fc20a00 R12: ffff9d4b6e42aa90
[69703.122506] R13: ffff9d4b0fc20ab8 R14: 00000000000003e8 R15: ffffbd6d0111837c
[69703.122514] FS:  00007fd5f2588740(0000) GS:ffff9d4b6e400000(0000) knlGS:0000000000000000
[69703.122521] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[69703.122528] CR2: ffffbd6d01117ff8 CR3: 00000000565d8001 CR4: 00000000003606f0
[69703.122538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[69703.122545] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[69703.122552] Call Trace:
[69703.122568]  ftrace_graph_caller+0x6b/0xa0
[69703.122589]  ? read_hv_sched_clock_tsc+0x5/0x20
[69703.122599]  read_hv_sched_clock_tsc+0x5/0x20
[69703.122611]  sched_clock+0x5/0x10
[69703.122621]  sched_clock_local+0x12/0x80
[69703.122631]  sched_clock_cpu+0x8c/0xb0
[69703.122644]  trace_clock_global+0x21/0x90
[69703.122655]  ring_buffer_lock_reserve+0x100/0x3c0
[69703.122671]  trace_buffer_lock_reserve+0x16/0x50
[69703.122683]  __trace_graph_entry+0x28/0x90
[69703.122695]  trace_graph_entry+0xfd/0x1a0
[69703.122705]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122714]  ? sched_clock+0x5/0x10
[69703.122723]  prepare_ftrace_return+0x99/0x110
[69703.122734]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122743]  ? sched_clock+0x5/0x10
[69703.122752]  ftrace_graph_caller+0x6b/0xa0
[69703.122768]  ? read_hv_clock_tsc_cs+0x10/0x10
[69703.122777]  ? sched_clock+0x5/0x10
[69703.122786]  ? read_hv_sched_clock_tsc+0x5/0x20
[69703.122796]  ? ring_buffer_unlock_commit+0x1d/0xa0
[69703.122805]  read_hv_sched_clock_tsc+0x5/0x20
[69703.122814]  ftrace_graph_caller+0xa0/0xa0
[ ... recursion snipped ... ]

Setting the notrace attribute for read_hv_sched_clock_msr() and
read_hv_sched_clock_tsc() fixes it.

Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function")
Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Mohammed Gamal &lt;mgamal@redhat.com&gt;
Link: https://lore.kernel.org/r/20200924151117.767442-1-mgamal@redhat.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'timers-core-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2020-03-31T01:51:47+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-03-31T01:51:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dbb381b619aa5242c9cb1a8fd54d71c4d79c91eb'/>
<id>dbb381b619aa5242c9cb1a8fd54d71c4d79c91eb</id>
<content type='text'>
Pull timekeeping and timer updates from Thomas Gleixner:
 "Core:

   - Consolidation of the vDSO build infrastructure to address the
     difficulties of cross-builds for ARM64 compat vDSO libraries by
     restricting the exposure of header content to the vDSO build.

     This is achieved by splitting out header content into separate
     headers. which contain only the minimaly required information which
     is necessary to build the vDSO. These new headers are included from
     the kernel headers and the vDSO specific files.

   - Enhancements to the generic vDSO library allowing more fine grained
     control over the compiled in code, further reducing architecture
     specific storage and preparing for adopting the generic library by
     PPC.

   - Cleanup and consolidation of the exit related code in posix CPU
     timers.

   - Small cleanups and enhancements here and there

  Drivers:

   - The obligatory new drivers: Ingenic JZ47xx and X1000 TCU support

   - Correct the clock rate of PIT64b global clock

   - setup_irq() cleanup

   - Preparation for PWM and suspend support for the TI DM timer

   - Expand the fttmr010 driver to support ast2600 systems

   - The usual small fixes, enhancements and cleanups all over the
     place"

* tag 'timers-core-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (80 commits)
  Revert "clocksource/drivers/timer-probe: Avoid creating dead devices"
  vdso: Fix clocksource.h macro detection
  um: Fix header inclusion
  arm64: vdso32: Enable Clang Compilation
  lib/vdso: Enable common headers
  arm: vdso: Enable arm to use common headers
  x86/vdso: Enable x86 to use common headers
  mips: vdso: Enable mips to use common headers
  arm64: vdso32: Include common headers in the vdso library
  arm64: vdso: Include common headers in the vdso library
  arm64: Introduce asm/vdso/processor.h
  arm64: vdso32: Code clean up
  linux/elfnote.h: Replace elf.h with UAPI equivalent
  scripts: Fix the inclusion order in modpost
  common: Introduce processor.h
  linux/ktime.h: Extract common header for vDSO
  linux/jiffies.h: Extract common header for vDSO
  linux/time64.h: Extract common header for vDSO
  linux/time32.h: Extract common header for vDSO
  linux/time.h: Extract common header for vDSO
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull timekeeping and timer updates from Thomas Gleixner:
 "Core:

   - Consolidation of the vDSO build infrastructure to address the
     difficulties of cross-builds for ARM64 compat vDSO libraries by
     restricting the exposure of header content to the vDSO build.

     This is achieved by splitting out header content into separate
     headers. which contain only the minimaly required information which
     is necessary to build the vDSO. These new headers are included from
     the kernel headers and the vDSO specific files.

   - Enhancements to the generic vDSO library allowing more fine grained
     control over the compiled in code, further reducing architecture
     specific storage and preparing for adopting the generic library by
     PPC.

   - Cleanup and consolidation of the exit related code in posix CPU
     timers.

   - Small cleanups and enhancements here and there

  Drivers:

   - The obligatory new drivers: Ingenic JZ47xx and X1000 TCU support

   - Correct the clock rate of PIT64b global clock

   - setup_irq() cleanup

   - Preparation for PWM and suspend support for the TI DM timer

   - Expand the fttmr010 driver to support ast2600 systems

   - The usual small fixes, enhancements and cleanups all over the
     place"

* tag 'timers-core-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (80 commits)
  Revert "clocksource/drivers/timer-probe: Avoid creating dead devices"
  vdso: Fix clocksource.h macro detection
  um: Fix header inclusion
  arm64: vdso32: Enable Clang Compilation
  lib/vdso: Enable common headers
  arm: vdso: Enable arm to use common headers
  x86/vdso: Enable x86 to use common headers
  mips: vdso: Enable mips to use common headers
  arm64: vdso32: Include common headers in the vdso library
  arm64: vdso: Include common headers in the vdso library
  arm64: Introduce asm/vdso/processor.h
  arm64: vdso32: Code clean up
  linux/elfnote.h: Replace elf.h with UAPI equivalent
  scripts: Fix the inclusion order in modpost
  common: Introduce processor.h
  linux/ktime.h: Extract common header for vDSO
  linux/jiffies.h: Extract common header for vDSO
  linux/time64.h: Extract common header for vDSO
  linux/time32.h: Extract common header for vDSO
  linux/time.h: Extract common header for vDSO
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyper-v: Make sched clock return nanoseconds correctly</title>
<updated>2020-03-27T11:27:45+00:00</updated>
<author>
<name>Yubo Xie</name>
<email>yuboxie@microsoft.com</email>
</author>
<published>2020-03-27T02:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=749da8ca978f19710aba496208c480ad42d37f79'/>
<id>749da8ca978f19710aba496208c480ad42d37f79</id>
<content type='text'>
The sched clock read functions return the HV clock (100ns granularity)
without converting it to nanoseconds.

Add the missing conversion.

Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function")
Signed-off-by: Yubo Xie &lt;yuboxie@microsoft.com&gt;
Signed-off-by: Tianyu Lan &lt;Tianyu.Lan@microsoft.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200327021159.31429-1-Tianyu.Lan@microsoft.com

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The sched clock read functions return the HV clock (100ns granularity)
without converting it to nanoseconds.

Add the missing conversion.

Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function")
Signed-off-by: Yubo Xie &lt;yuboxie@microsoft.com&gt;
Signed-off-by: Tianyu Lan &lt;Tianyu.Lan@microsoft.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200327021159.31429-1-Tianyu.Lan@microsoft.com

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/vdso: Move VDSO clocksource state tracking to callback</title>
<updated>2020-02-17T13:40:22+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-02-07T12:38:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=eec399dd862762b9594df3659f15839a4e12f17a'/>
<id>eec399dd862762b9594df3659f15839a4e12f17a</id>
<content type='text'>
All architectures which use the generic VDSO code have their own storage
for the VDSO clock mode. That's pointless and just requires duplicate code.

X86 abuses the function which retrieves the architecture specific clock
mode storage to mark the clocksource as used in the VDSO. That's silly
because this is invoked on every tick when the VDSO data is updated.

Move this functionality to the clocksource::enable() callback so it gets
invoked once when the clocksource is installed. This allows to make the
clock mode storage generic.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;  (Hyper-V parts)
Reviewed-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt; (VDSO parts)
Acked-by: Juergen Gross &lt;jgross@suse.com&gt; (Xen parts)
Link: https://lkml.kernel.org/r/20200207124402.934519777@linutronix.de


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All architectures which use the generic VDSO code have their own storage
for the VDSO clock mode. That's pointless and just requires duplicate code.

X86 abuses the function which retrieves the architecture specific clock
mode storage to mark the clocksource as used in the VDSO. That's silly
because this is invoked on every tick when the VDSO data is updated.

Move this functionality to the clocksource::enable() callback so it gets
invoked once when the clocksource is installed. This allows to make the
clock mode storage generic.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;  (Hyper-V parts)
Reviewed-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt; (VDSO parts)
Acked-by: Juergen Gross &lt;jgross@suse.com&gt; (Xen parts)
Link: https://lkml.kernel.org/r/20200207124402.934519777@linutronix.de


</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyper-v: Set TSC clocksource as default w/ InvariantTSC</title>
<updated>2020-01-16T18:09:02+00:00</updated>
<author>
<name>Andrea Parri</name>
<email>parri.andrea@gmail.com</email>
</author>
<published>2020-01-09T16:06:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9e0333ae38eeb42249e10f95d209244a6e22ac9f'/>
<id>9e0333ae38eeb42249e10f95d209244a6e22ac9f</id>
<content type='text'>
Change the Hyper-V clocksource ratings to 250, below the TSC clocksource
rating of 300.  In configurations where Hyper-V offers an InvariantTSC,
the TSC is not marked "unstable", so the TSC clocksource is available
and preferred.  With the higher rating, it will be the default.  On
older hardware and Hyper-V versions, the TSC is marked "unstable", so no
TSC clocksource is created and the selected Hyper-V clocksource will be
the default.

Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20200109160650.16150-3-parri.andrea@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change the Hyper-V clocksource ratings to 250, below the TSC clocksource
rating of 300.  In configurations where Hyper-V offers an InvariantTSC,
the TSC is not marked "unstable", so the TSC clocksource is available
and preferred.  With the higher rating, it will be the default.  On
older hardware and Hyper-V versions, the TSC is marked "unstable", so no
TSC clocksource is created and the selected Hyper-V clocksource will be
the default.

Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20200109160650.16150-3-parri.andrea@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyper-v: Untangle stimers and timesync from clocksources</title>
<updated>2020-01-16T18:09:02+00:00</updated>
<author>
<name>Andrea Parri</name>
<email>parri.andrea@gmail.com</email>
</author>
<published>2020-01-09T16:06:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0af3e137c144377fbaf5025ba784ff5ba7ad40c9'/>
<id>0af3e137c144377fbaf5025ba784ff5ba7ad40c9</id>
<content type='text'>
hyperv_timer.c exports hyperv_cs, which is used by stimers and the
timesync mechanism.  However, the clocksource dependency is not
needed: these mechanisms only depend on the partition reference
counter (which can be read via a MSR or via the TSC Reference Page).

Introduce the (function) pointer hv_read_reference_counter, as an
embodiment of the partition reference counter read, and export it
in place of the hyperv_cs pointer.  The latter can be removed.

This should clarify that there's no relationship between Hyper-V
stimers &amp; timesync and the Linux clocksource abstractions.  No
functional or semantic change.

Suggested-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20200109160650.16150-2-parri.andrea@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
hyperv_timer.c exports hyperv_cs, which is used by stimers and the
timesync mechanism.  However, the clocksource dependency is not
needed: these mechanisms only depend on the partition reference
counter (which can be read via a MSR or via the TSC Reference Page).

Introduce the (function) pointer hv_read_reference_counter, as an
embodiment of the partition reference counter read, and export it
in place of the hyperv_cs pointer.  The latter can be removed.

This should clarify that there's no relationship between Hyper-V
stimers &amp; timesync and the Linux clocksource abstractions.  No
functional or semantic change.

Suggested-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20200109160650.16150-2-parri.andrea@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyper-v: Reserve PAGE_SIZE space for tsc page</title>
<updated>2020-01-16T18:07:09+00:00</updated>
<author>
<name>Boqun Feng</name>
<email>boqun.feng@gmail.com</email>
</author>
<published>2019-11-26T02:17:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ddc61bbc45017726a2b450350d476b4dc5ae25ce'/>
<id>ddc61bbc45017726a2b450350d476b4dc5ae25ce</id>
<content type='text'>
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.

Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.

Signed-off-by: Boqun Feng (Microsoft) &lt;boqun.feng@gmail.com&gt;
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.

Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.

Signed-off-by: Boqun Feng (Microsoft) &lt;boqun.feng@gmail.com&gt;
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyper-v: Suspend/resume Hyper-V clocksource for hibernation</title>
<updated>2020-01-16T18:06:57+00:00</updated>
<author>
<name>Dexuan Cui</name>
<email>decui@microsoft.com</email>
</author>
<published>2019-11-20T07:12:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1349401ff1aa425e7381ed26feb63e0d6b557fc6'/>
<id>1349401ff1aa425e7381ed26feb63e0d6b557fc6</id>
<content type='text'>
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's TSC page and then resume the old kernel's.

Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/1574233946-48377-1-git-send-email-decui@microsoft.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's TSC page and then resume the old kernel's.

Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Link: https://lore.kernel.org/r/1574233946-48377-1-git-send-email-decui@microsoft.com
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/hyperv: Initialize clockevents earlier in CPU onlining</title>
<updated>2019-11-15T09:33:49+00:00</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2019-11-13T01:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4df4cb9e99f83b70d54bc0e25081ac23cceafcbc'/>
<id>4df4cb9e99f83b70d54bc0e25081ac23cceafcbc</id>
<content type='text'>
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.

Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process.  Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.

Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.

So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called.  But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Reviewed-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.

Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process.  Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.

Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.

So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called.  But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Reviewed-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource/drivers/hyperv: Enable TSC page clocksource on 32bit</title>
<updated>2019-08-23T14:59:54+00:00</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2019-08-22T08:36:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3e2d94535adb2df15f3907e4b4c7cd8a5a4c2b5a'/>
<id>3e2d94535adb2df15f3907e4b4c7cd8a5a4c2b5a</id>
<content type='text'>
There is no particular reason to not enable TSC page clocksource on
32-bit. mul_u64_u64_shr() is available and despite the increased
computational complexity (compared to 64bit) TSC page is still a huge win
compared to MSR-based clocksource.

In-kernel reads:
  MSR based clocksource: 3361 cycles
  TSC page clocksource: 49 cycles

Reads from userspace (utilizing vDSO in case of TSC page):
  MSR based clocksource: 5664 cycles
  TSC page clocksource: 131 cycles

Enabling TSC page on 32bits allows to get rid of CONFIG_HYPERV_TSCPAGE as
it is now not any different from CONFIG_HYPERV_TIMER.

Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lkml.kernel.org/r/20190822083630.17059-1-vkuznets@redhat.com

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is no particular reason to not enable TSC page clocksource on
32-bit. mul_u64_u64_shr() is available and despite the increased
computational complexity (compared to 64bit) TSC page is still a huge win
compared to MSR-based clocksource.

In-kernel reads:
  MSR based clocksource: 3361 cycles
  TSC page clocksource: 49 cycles

Reads from userspace (utilizing vDSO in case of TSC page):
  MSR based clocksource: 5664 cycles
  TSC page clocksource: 131 cycles

Enabling TSC page on 32bits allows to get rid of CONFIG_HYPERV_TSCPAGE as
it is now not any different from CONFIG_HYPERV_TIMER.

Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lkml.kernel.org/r/20190822083630.17059-1-vkuznets@redhat.com

</pre>
</div>
</content>
</entry>
</feed>
