<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/x86/include/asm/vdso, branch linux-5.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.14.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.14.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2021-05-14T12:55:13Z</updated>
<entry>
<title>clocksource/drivers/hyper-v: Re-enable VDSO_CLOCKMODE_HVCLOCK on X86</title>
<updated>2021-05-14T12:55:13Z</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2021-05-13T07:32:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3486d2c9be652a31033363bdd50391b0c8a8fe21'/>
<id>urn:sha1:3486d2c9be652a31033363bdd50391b0c8a8fe21</id>
<content type='text'>
Mohammed reports (https://bugzilla.kernel.org/show_bug.cgi?id=213029)
the commit e4ab4658f1cf ("clocksource/drivers/hyper-v: Handle vDSO
differences inline") broke vDSO on x86. The problem appears to be that
VDSO_CLOCKMODE_HVCLOCK is an enum value in 'enum vdso_clock_mode' and
'#ifdef VDSO_CLOCKMODE_HVCLOCK' branch evaluates to false (it is not
a define).

Use a dedicated HAVE_VDSO_CLOCKMODE_HVCLOCK define instead.

Fixes: e4ab4658f1cf ("clocksource/drivers/hyper-v: Handle vDSO differences inline")
Reported-by: Mohammed Gamal &lt;mgamal@redhat.com&gt;
Suggested-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
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://lore.kernel.org/r/20210513073246.1715070-1-vkuznets@redhat.com

</content>
</entry>
<entry>
<title>lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data()</title>
<updated>2021-04-14T13:04:44Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2021-03-31T16:48:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=808094fcbf4196be0feb17afbbdc182ec95c8cec'/>
<id>urn:sha1:808094fcbf4196be0feb17afbbdc182ec95c8cec</id>
<content type='text'>
For the same reason as commit e876f0b69dc9 ("lib/vdso: Allow
architectures to provide the vdso data pointer"), powerpc wants to
avoid calculation of relative position to code.

As the timens_vdso_data is next page to vdso_data, provide
vdso_data pointer to __arch_get_timens_vdso_data() in order
to ease the calculation on powerpc in following patches.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Reviewed-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Acked-by: Andrei Vagin &lt;avagin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/539c4204b1baa77c55f758904a1ea239abbc7a5c.1617209142.git.christophe.leroy@csgroup.eu
</content>
</entry>
<entry>
<title>vdso/treewide: Add vdso_data pointer argument to __arch_get_hw_counter()</title>
<updated>2020-08-06T08:57:30Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-08-04T20:37:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4c5a116ada953b86125ab7c70a57c57463a55a55'/>
<id>urn:sha1:4c5a116ada953b86125ab7c70a57c57463a55a55</id>
<content type='text'>
MIPS already uses and S390 will need the vdso data pointer in
__arch_get_hw_counter().

This works nicely as long as the architecture does not support time
namespaces in the VDSO. With time namespaces enabled the regular
accessor to the vdso data pointer __arch_get_vdso_data() will return the
namespace specific VDSO data page for tasks which are part of a
non-root time namespace. This would cause the architectures which need
the vdso data pointer in __arch_get_hw_counter() to access the wrong
vdso data page.

Add a vdso_data pointer argument to __arch_get_hw_counter() and hand it in
from the call sites in the core code. For architectures which do not need
the data pointer in their counter accessor function the compiler will just
optimize it out.

Fix up all existing architecture implementations and make MIPS utilize the
pointer instead of invoking the accessor function.

No functional change and no change in the resulting object code (except
MIPS).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/draft-87wo2ekuzn.fsf@nanos.tec.linutronix.de
</content>
</entry>
<entry>
<title>x86/vdso: Unbreak paravirt VDSO clocks</title>
<updated>2020-06-09T14:36:49Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-06-06T21:51:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7778d8417b74aded842eeb372961cfc460417fa0'/>
<id>urn:sha1:7778d8417b74aded842eeb372961cfc460417fa0</id>
<content type='text'>
The conversion of x86 VDSO to the generic clock mode storage broke the
paravirt and hyperv clocksource logic. These clock sources have their own
internal sequence counter to validate the clocksource at the point of
reading it. This is necessary because the hypervisor can invalidate the
clocksource asynchronously so a check during the VDSO data update is not
sufficient. If the internal check during read invalidates the clocksource
the read return U64_MAX. The original code checked this efficiently by
testing whether the result (casted to signed) is negative, i.e. bit 63 is
set. This was done that way because an extra indicator for the validity had
more overhead.

The conversion broke this check because the check was replaced by a check
for a valid VDSO clock mode.

The wreckage manifests itself when the paravirt clock is installed as a
valid VDSO clock and during runtime invalidated by the hypervisor,
e.g. after a host suspend/resume cycle. After the invalidation the read
function returns U64_MAX which is used as cycles and makes the clock jump
by ~2200 seconds, and become stale until the 2200 seconds have elapsed
where it starts to jump again. The period of this effect depends on the
shift/mult pair of the clocksource and the jumps and staleness are an
artifact of undefined but reproducible behaviour of math overflow.

Implement an x86 version of the new vdso_cycles_ok() inline which adds this
check back and a variant of vdso_clocksource_ok() which lets the compiler
optimize it out to avoid the extra conditional. That's suboptimal when the
system does not have a VDSO capable clocksource, but that's not the case
which is optimized for.

Fixes: 5d51bee725cc ("clocksource: Add common vdso clock mode storage")
Reported-by: Miklos Szeredi &lt;miklos@szeredi.hu&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200606221532.080560273@linutronix.de

</content>
</entry>
<entry>
<title>x86/vdso: Enable x86 to use common headers</title>
<updated>2020-03-21T14:24:02Z</updated>
<author>
<name>Vincenzo Frascino</name>
<email>vincenzo.frascino@arm.com</email>
</author>
<published>2020-03-20T14:53:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=abc22418db02b986fc5623c035507b6357e191ed'/>
<id>urn:sha1:abc22418db02b986fc5623c035507b6357e191ed</id>
<content type='text'>
Enable x86 to use only the common headers in the implementation
of the vDSO library.

Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/20200320145351.32292-24-vincenzo.frascino@arm.com

</content>
</entry>
<entry>
<title>x86: Introduce asm/vdso/clocksource.h</title>
<updated>2020-03-21T14:23:54Z</updated>
<author>
<name>Vincenzo Frascino</name>
<email>vincenzo.frascino@arm.com</email>
</author>
<published>2020-03-20T14:53:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=659a9faa3f3c89de4c34c30c3da676059864e0fe'/>
<id>urn:sha1:659a9faa3f3c89de4c34c30c3da676059864e0fe</id>
<content type='text'>
The vDSO library should only include the necessary headers required for
a userspace library (UAPI and a minimal set of kernel headers). To make
this possible it is necessary to isolate from the kernel headers the
common parts that are strictly necessary to build the library.

Introduce asm/vdso/clocksource.h to contain all the arm64 specific
functions that are suitable for vDSO inclusion.

This header will be required by a future patch that will generalize
vdso/clocksource.h.

Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/20200320145351.32292-5-vincenzo.frascino@arm.com

</content>
</entry>
<entry>
<title>x86/vdso: Use generic VDSO clock mode storage</title>
<updated>2020-02-17T13:40:23Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-02-07T12:38:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b95a8a27c300d1a39a4e36f63a518ef36e4b966c'/>
<id>urn:sha1:b95a8a27c300d1a39a4e36f63a518ef36e4b966c</id>
<content type='text'>
Switch to the generic VDSO clock mode storage.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt; (VDSO parts)
Acked-by: Juergen Gross &lt;jgross@suse.com&gt; (Xen parts)
Acked-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt; (KVM parts)
Link: https://lkml.kernel.org/r/20200207124403.152039903@linutronix.de


</content>
</entry>
<entry>
<title>x86/vdso: Move VDSO clocksource state tracking to callback</title>
<updated>2020-02-17T13:40:22Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-02-07T12:38:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=eec399dd862762b9594df3659f15839a4e12f17a'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>x86/vdso: Mark the TSC clocksource path likely</title>
<updated>2020-02-17T13:40:19Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-02-07T12:38:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=50e818715821b89c7abac90a97721f106e893d83'/>
<id>urn:sha1:50e818715821b89c7abac90a97721f106e893d83</id>
<content type='text'>
Jumping out of line for the TSC clcoksource read is creating awful
code. TSC is likely to be the clocksource at least on bare metal and the PV
interfaces are sufficiently more work that the jump over the TSC read is
just in the noise.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Link: https://lkml.kernel.org/r/20200207124402.328922847@linutronix.de

</content>
</entry>
<entry>
<title>x86/vdso: Add time napespace page</title>
<updated>2020-01-14T11:20:58Z</updated>
<author>
<name>Dmitry Safonov</name>
<email>dima@arista.com</email>
</author>
<published>2019-11-12T01:27:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=550a77a74c87ecfdadc2214fef4b25ff125f65ab'/>
<id>urn:sha1:550a77a74c87ecfdadc2214fef4b25ff125f65ab</id>
<content type='text'>
To support time namespaces in the VDSO with a minimal impact on regular non
time namespace affected tasks, the namespace handling needs to be hidden in
a slow path.

The most obvious place is vdso_seq_begin(). If a task belongs to a time
namespace then the VVAR page which contains the system wide VDSO data is
replaced with a namespace specific page which has the same layout as the
VVAR page. That page has vdso_data-&gt;seq set to 1 to enforce the slow path
and vdso_data-&gt;clock_mode set to VCLOCK_TIMENS to enforce the time
namespace handling path.

The extra check in the case that vdso_data-&gt;seq is odd, e.g. a concurrent
update of the VDSO data is in progress, is not really affecting regular
tasks which are not part of a time namespace as the task is spin waiting
for the update to finish and vdso_data-&gt;seq to become even again.

If a time namespace task hits that code path, it invokes the corresponding
time getter function which retrieves the real VVAR page, reads host time
and then adds the offset for the requested clock which is stored in the
special VVAR page.

Allocate the time namespace page among VVAR pages and place vdso_data on
it.  Provide __arch_get_timens_vdso_data() helper for VDSO code to get the
code-relative position of VVARs on that special page.

Co-developed-by: Andrei Vagin &lt;avagin@openvz.org&gt;
Signed-off-by: Andrei Vagin &lt;avagin@openvz.org&gt;
Signed-off-by: Dmitry Safonov &lt;dima@arista.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/20191112012724.250792-23-dima@arista.com


</content>
</entry>
</feed>
