All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"yangbo.lu@nxp.com" <yangbo.lu@nxp.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	"maz@kernel.org" <maz@kernel.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Steve Capper <Steve.Capper@arm.com>,
	"Kaly Xin (Arm Technology China)" <Kaly.Xin@arm.com>,
	"Justin He (Arm Technology China)" <Justin.He@arm.com>,
	nd <nd@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
Date: Tue, 24 Sep 2019 16:20:14 +0200	[thread overview]
Message-ID: <06264d8a-b9c0-5f19-db2c-6190976a2a05@redhat.com> (raw)
In-Reply-To: <HE1PR0801MB1676A9D4A58118144F5C7B54F4850@HE1PR0801MB1676.eurprd08.prod.outlook.com>

On 23/09/19 06:57, Jianyong Wu (Arm Technology China) wrote:
>> On 19/09/19 11:46, Jianyong Wu (Arm Technology China) wrote:
>>>> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
>>>>> Paolo Bonzini wrote:
>>>>>> This is not Y2038-safe.  Please use ktime_get_real_ts64 instead,
>>>>>> and split the 64-bit seconds value between val[0] and val[1].
>>>
>>> Val[] should be long not u32 I think, so in arm64 I can avoid that
>>> Y2038_safe, but also need rewrite for arm32.
>>
>> I don't think there's anything inherently wrong with u32 val[], and as you
>> notice it lets you reuse code between arm and arm64.  It's up to you and
>> Marc to decide.
>>
> To compatible 32-bit, Integrates second value and nanosecond value as a nanosecond value then split it into val[0] and val[1] and split cycle value into val[2] and val[3],
>  In this way, time will overflow at Y2262.
> WDYT?

So if I understand correctly you'd multiply by 10^9 (or better shift by
30) the nanoseconds.

That works, but why not provide 5 output registers?  Alternatively, take
an address as input and write there.

Finally, on x86 we added an argument for the CLOCK_* that is being read
(currently only CLOCK_REALTIME, but having room for extensibility in the
API is always nice).

Paolo


WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"yangbo.lu@nxp.com" <yangbo.lu@nxp.com>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	"maz@kernel.org" <maz@kernel.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>
Cc: "Justin He \(Arm Technology China\)" <Justin.He@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Steve Capper <Steve.Capper@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kaly Xin \(Arm Technology China\)" <Kaly.Xin@arm.com>,
	nd <nd@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
Date: Tue, 24 Sep 2019 16:20:14 +0200	[thread overview]
Message-ID: <06264d8a-b9c0-5f19-db2c-6190976a2a05@redhat.com> (raw)
In-Reply-To: <HE1PR0801MB1676A9D4A58118144F5C7B54F4850@HE1PR0801MB1676.eurprd08.prod.outlook.com>

On 23/09/19 06:57, Jianyong Wu (Arm Technology China) wrote:
>> On 19/09/19 11:46, Jianyong Wu (Arm Technology China) wrote:
>>>> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
>>>>> Paolo Bonzini wrote:
>>>>>> This is not Y2038-safe.  Please use ktime_get_real_ts64 instead,
>>>>>> and split the 64-bit seconds value between val[0] and val[1].
>>>
>>> Val[] should be long not u32 I think, so in arm64 I can avoid that
>>> Y2038_safe, but also need rewrite for arm32.
>>
>> I don't think there's anything inherently wrong with u32 val[], and as you
>> notice it lets you reuse code between arm and arm64.  It's up to you and
>> Marc to decide.
>>
> To compatible 32-bit, Integrates second value and nanosecond value as a nanosecond value then split it into val[0] and val[1] and split cycle value into val[2] and val[3],
>  In this way, time will overflow at Y2262.
> WDYT?

So if I understand correctly you'd multiply by 10^9 (or better shift by
30) the nanoseconds.

That works, but why not provide 5 output registers?  Alternatively, take
an address as input and write there.

Finally, on x86 we added an argument for the CLOCK_* that is being read
(currently only CLOCK_REALTIME, but having room for extensibility in the
API is always nice).

Paolo


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-24 14:20 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18  8:07 [RFC PATCH v3 0/6] Enable ptp_kvm for arm64 Jianyong Wu
2019-09-18  8:07 ` Jianyong Wu
2019-09-18  8:07 ` [RFC PATCH v3 1/6] psci: Export psci_ops.conduit symbol as modules will use it Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu
2019-09-18  8:07 ` [RFC PATCH v3 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu
2019-09-18  8:07 ` [RFC PATCH v3 3/6] timekeeping: Expose API allowing retrival of current clocksource and counter value Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu
2019-09-18  8:29   ` Paolo Bonzini
2019-09-18  8:29     ` Paolo Bonzini
2019-09-18  8:07 ` [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu
2019-09-18  8:25   ` Paolo Bonzini
2019-09-18  8:25     ` Paolo Bonzini
2019-09-18  9:57     ` Jianyong Wu (Arm Technology China)
2019-09-18  9:57       ` Jianyong Wu (Arm Technology China)
2019-09-18 10:23       ` Paolo Bonzini
2019-09-18 10:23         ` Paolo Bonzini
2019-09-19  9:46         ` Jianyong Wu (Arm Technology China)
2019-09-19  9:46           ` Jianyong Wu (Arm Technology China)
2019-09-19 11:07           ` Paolo Bonzini
2019-09-19 11:07             ` Paolo Bonzini
2019-09-19 11:39             ` Marc Zyngier
2019-09-19 11:39               ` Marc Zyngier
2019-09-19 12:13               ` Paolo Bonzini
2019-09-19 12:13                 ` Paolo Bonzini
2019-09-23  3:19                 ` Jianyong Wu (Arm Technology China)
2019-09-23  3:19                   ` Jianyong Wu (Arm Technology China)
2019-10-09  5:21                 ` Jianyong Wu (Arm Technology China)
2019-10-09  5:21                   ` Jianyong Wu (Arm Technology China)
2019-10-09  6:36                   ` Paolo Bonzini
2019-10-09  6:36                     ` Paolo Bonzini
2019-10-09  8:18                     ` Jianyong Wu (Arm Technology China)
2019-10-09  8:18                       ` Jianyong Wu (Arm Technology China)
2019-10-09  9:13                       ` Paolo Bonzini
2019-10-09  9:13                         ` Paolo Bonzini
2019-10-09 16:05                         ` John Stultz
2019-10-09 16:05                           ` John Stultz
2019-10-09 16:05                           ` John Stultz
2019-10-09 20:56                           ` Paolo Bonzini
2019-10-09 20:56                             ` Paolo Bonzini
2019-10-14  5:50                         ` Jianyong Wu (Arm Technology China)
2019-10-14  5:50                           ` Jianyong Wu (Arm Technology China)
2019-10-14  6:58                           ` Paolo Bonzini
2019-10-14  6:58                             ` Paolo Bonzini
2019-09-23  4:57             ` Jianyong Wu (Arm Technology China)
2019-09-23  4:57               ` Jianyong Wu (Arm Technology China)
2019-09-24 14:20               ` Paolo Bonzini [this message]
2019-09-24 14:20                 ` Paolo Bonzini
2019-09-25 10:27                 ` Jianyong Wu (Arm Technology China)
2019-09-25 10:27                   ` Jianyong Wu (Arm Technology China)
2019-09-18  8:07 ` [RFC PATCH v3 5/6] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu
2019-09-18  8:07 ` [RFC PATCH v3 6/6] kvm: arm64: Add capability check extension for ptp_kvm Jianyong Wu
2019-09-18  8:07   ` Jianyong Wu

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=06264d8a-b9c0-5f19-db2c-6190976a2a05@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=Jianyong.Wu@arm.com \
    --cc=Justin.He@arm.com \
    --cc=Kaly.Xin@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=john.stultz@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=nd@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yangbo.lu@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.