[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <HE1PR0801MB1676F57B317AE85E3B934B32F48E0@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Date: Wed, 18 Sep 2019 09:57:07 +0000
From: "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@....com>
To: Paolo Bonzini <pbonzini@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"yangbo.lu@....com" <yangbo.lu@....com>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
"maz@...nel.org" <maz@...nel.org>,
"richardcochran@...il.com" <richardcochran@...il.com>,
Mark Rutland <Mark.Rutland@....com>,
Will Deacon <Will.Deacon@....com>,
Suzuki Poulose <Suzuki.Poulose@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Steve Capper <Steve.Capper@....com>,
"Kaly Xin (Arm Technology China)" <Kaly.Xin@....com>,
"Justin He (Arm Technology China)" <Justin.He@....com>,
nd <nd@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@...hat.com>
> Sent: Wednesday, September 18, 2019 4:26 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@....com>;
> netdev@...r.kernel.org; yangbo.lu@....com; john.stultz@...aro.org;
> tglx@...utronix.de; sean.j.christopherson@...el.com; maz@...nel.org;
> richardcochran@...il.com; Mark Rutland <Mark.Rutland@....com>; Will
> Deacon <Will.Deacon@....com>; Suzuki Poulose
> <Suzuki.Poulose@....com>
> Cc: linux-kernel@...r.kernel.org; kvm@...r.kernel.org; Steve Capper
> <Steve.Capper@....com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@....com>; Justin He (Arm Technology China)
> <Justin.He@....com>; nd <nd@....com>; linux-arm-
> kernel@...ts.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 18/09/19 10:07, Jianyong Wu wrote:
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + getnstimeofday(ts);
>
> 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].
>
As far as I know, y2038-safe will only affect signed 32-bit integer, how does it affect 64-bit integer?
And why split 64-bit number into two blocks is necessary?
Also, split number will lead to shortage of return value.
> However, it seems to me that the new function is not needed and you can
> just use ktime_get_snapshot. You'll get the time in systime_snapshot->real
> and the cycles value in systime_snapshot->cycles.
See patch 5/6, I need both counter cycle and clocksource, ktime_get_snapshot seems only offer cycles.
>
> > + get_current_counterval(&sc);
> > + val[0] = ts->tv_sec;
> > + val[1] = ts->tv_nsec;
> > + val[2] = sc.cycles;
> > + val[3] = 0;
> > + break;
>
> This should return a guest-cycles value. If the cycles values always the same
> between the host and the guest on ARM, then okay. If not, you have to
> apply whatever offset exists.
>
In my opinion, when use ptp_kvm as clock sources to sync time between host and guest, user should promise the guest and host has no
clock offset. So we can be sure that the cycle between guest and host should be keep consistent. But I need check it.
I think host cycle should be returned to guest as we should promise we get clock and counter in the same time.
Thanks
Jianyong Wu
> Thanks,
>
> Paolo
Powered by blists - more mailing lists