Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

Andy Lutomirski [off-list ref] writes:

On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Thomas Gleixner [mailto:tglx@linutronix.de]
Sent: Thursday, February 9, 2017 9:08 AM
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: x86@kernel.org; Andy Lutomirski <luto@amacapital.net>; Ingo Molnar
[off-list ref]; H. Peter Anvin [off-list ref]; KY Srinivasan
[off-list ref]; Haiyang Zhang [off-list ref]; Stephen
Hemminger [off-list ref]; Dexuan Cui
[off-list ref]; linux-kernel@vger.kernel.org;
devel@linuxdriverproject.org; virtualization@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:

quoted

+#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;
+
+   while (1) {
+           sequence = READ_ONCE(tsc_pg->tsc_sequence);
+           if (!sequence)
+                   break;
+
+           scale = READ_ONCE(tsc_pg->tsc_scale);
+           offset = READ_ONCE(tsc_pg->tsc_offset);
+           rdtscll(cur_tsc);
+
+           current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset;
+
+           if (READ_ONCE(tsc_pg->tsc_sequence) == sequence)
+                   return current_tick;

That sequence stuff lacks still a sensible explanation. It's fundamentally
different from the sequence counting we do in the kernel, so documentation
for it is really required.

The host is updating multiple fields in this shared TSC page and the sequence number is
used to ensure that the guest sees a consistent set values published. If I remember
correctly, Xen has a similar mechanism.

So what's the actual protocol?  When the hypervisor updates the page,
does it freeze all guest cpus?  If not, how does it maintain
atomicity?

I don't really know how it is implemented server-side but I *think* that
freezing all CPUs is only required when we want to update *both*
ReferenceTscScale and ReferenceTscOffset at the same time (as Hyper-V is
64-bit only so it can always atomically update 64-bit values)...

-- 
  Vitaly