linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Radim Krcmar <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Richard Cochran <richardcochran@gmail.com>,
	Miroslav Lichvar <mlichvar@redhat.com>
Subject: Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure
Date: Fri, 20 Jan 2017 15:02:16 +0100	[thread overview]
Message-ID: <20170120140216.GA1358@potion> (raw)
In-Reply-To: <2d213ad9-fa40-1f1e-90a9-404764969d35@redhat.com>

2017-01-20 14:36+0100, Paolo Bonzini:
> On 20/01/2017 14:07, Marcelo Tosatti wrote:
>> On Fri, Jan 20, 2017 at 01:55:27PM +0100, Paolo Bonzini wrote:
>>>
>>>
>>> On 20/01/2017 13:20, Marcelo Tosatti wrote:
>>>>  kernel/time/timekeeping.c        |   79 +++++++++++++++++++++++++++++++++++++++
>>>
>>> Why not leave this in drivers/ptp/ptp_chardev.c?
>> 
>> timekeeper_lock
> 
> Why does emulate_ptp_sys_offset need it, if the current PTP_SYS_OFFSET
> code doesn't?  Is the latency acceptable (considering this is a raw spin
> lock) or is there a seqlock that we can use instead (such as tk_core.seq
> like in get_device_system_crosststamp)?

The spinlock prevents writers to take the tk_core.seq, which means that
time cannot be changed during that.

The simplest alternative would be to use tk_core.seq for all our reads,
but that would increse the chance of re-reading, even infinitely.

But we don't need to read everything with the same time base -- if the
time is changed (by NTP/user/...) between our reads, then the value will
be off, but if writer took tk_core.seq just to accumulate current time,
then the time after accumulation stays the same and it would work as if
we had the tk_core.seq for the whole time.

Another solution would be to do just one one read and set it to all
saples -- the difference between t[i] and t[i+2] would be 0.  We are
quite sure the just one read is enough, this hack could be even better.

>>>> +		if (ptp->info->emulate_ptp_sys_offset_mean) {
>>>> +			err = emulate_ptp_sys_offset(ptp->info, sysoff, arg);
>>>> +			break;
>>>> +		}
>>>
>>> I think this should be simply "if (!ptp->info->gettime64)" and,
>>> likewise, there should be an emulation based getcrosststamp in
>>> ptp_clock_gettime.
>>>
>>> Paolo
>> 
>> gettime64 is called directly via ptp_clock_gettime.
> 
> Yes, but ptp_clock_gettime can be taught to use getcrosststamp instead.

I agree,

  if (!gettime64)
      use getcrosststamp

and KVM PTP device will not implement gettime64().

  parent reply	other threads:[~2017-01-20 14:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-20 12:20 [patch 0/5] KVM virtual PTP driver (v3) Marcelo Tosatti
2017-01-20 12:20 ` [patch 1/5] KVM: x86: provide realtime host clock via vsyscall notifiers Marcelo Tosatti
2017-01-20 12:20 ` [patch 2/5] KVM: x86: add KVM_HC_CLOCK_OFFSET hypercall Marcelo Tosatti
2017-01-20 12:20 ` [patch 3/5] kvmclock: export kvmclock clocksource pointer Marcelo Tosatti
2017-01-20 12:55   ` Paolo Bonzini
2017-01-20 12:20 ` [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure Marcelo Tosatti
2017-01-20 12:55   ` Paolo Bonzini
2017-01-20 13:07     ` Marcelo Tosatti
2017-01-20 13:36       ` Paolo Bonzini
2017-01-20 13:52         ` Marcelo Tosatti
2017-01-20 14:02         ` Radim Krcmar [this message]
2017-01-20 14:23           ` Paolo Bonzini
2017-01-20 14:31             ` Miroslav Lichvar
2017-01-20 18:30             ` Radim Krcmar
2017-01-20 20:25   ` Richard Cochran
2017-01-23 13:19     ` Marcelo Tosatti
2017-01-23 18:44       ` Richard Cochran
2017-01-23 19:44         ` Paolo Bonzini
2017-01-24  5:43           ` Richard Cochran
2017-01-24 11:23           ` Marcelo Tosatti
2017-01-24 11:35             ` Richard Cochran
2017-01-23 23:06         ` Marcelo Tosatti
2017-01-24  5:32           ` Richard Cochran
2017-01-24  8:15             ` Miroslav Lichvar
2017-01-20 12:20 ` [patch 5/5] PTP: add kvm PTP driver Marcelo Tosatti
2017-01-20 12:58   ` Paolo Bonzini
2017-01-20 13:11     ` Marcelo Tosatti
2017-01-20 14:12   ` Radim Krcmar
2017-01-20 14:20     ` Radim Krcmar
2017-01-20 15:00     ` Marcelo Tosatti
2017-01-20 17:11       ` Paolo Bonzini
2017-01-20 18:08       ` Radim Krcmar
2017-01-20 19:10         ` Marcelo Tosatti
2017-01-21  8:02         ` Paolo Bonzini
2017-01-20 13:10 ` [patch 0/5] KVM virtual PTP driver (v3) Paolo Bonzini
2017-01-20 14:51 [patch 0/5] KVM virtual PTP driver (v4) Marcelo Tosatti
2017-01-20 14:51 ` [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170120140216.GA1358@potion \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlichvar@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).