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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan <kys@xxxxxxxxxxxxx> wrote:
>
>
>> -----Original Message-----
>> From: Thomas Gleixner [mailto:tglx@xxxxxxxxxxxxx]
>> Sent: Thursday, February 9, 2017 9:08 AM
>> To: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>> Cc: x86@xxxxxxxxxx; Andy Lutomirski <luto@xxxxxxxxxxxxxx>; Ingo Molnar
>> <mingo@xxxxxxxxxx>; H. Peter Anvin <hpa@xxxxxxxxx>; KY Srinivasan
>> <kys@xxxxxxxxxxxxx>; Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; Stephen
>> Hemminger <sthemmin@xxxxxxxxxxxxx>; Dexuan Cui
>> <decui@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
>> devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
>> 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, 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?

--Andy
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux