Messages in this thread | | | From | Jianyong Wu <> | Subject | RE: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64 | Date | Tue, 14 Jan 2020 10:22:16 +0000 |
| |
Hi Marc,
> -----Original Message----- > From: Marc Zyngier <maz@kernel.org> > Sent: Monday, January 13, 2020 7:21 PM > To: Jianyong Wu <Jianyong.Wu@arm.com> > Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org; > tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com; > richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>; > will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Steven Price > <Steven.Price@arm.com>; linux-kernel@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; Kaly Xin > <Kaly.Xin@arm.com>; Justin He <Justin.He@arm.com>; nd <nd@arm.com> > Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64 > > On 2020-01-13 10:37, Jianyong Wu wrote: > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Zyngier <maz@kernel.org> > >> Sent: Friday, January 10, 2020 6:35 PM > >> To: Jianyong Wu <Jianyong.Wu@arm.com> > >> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; > >> john.stultz@linaro.org; tglx@linutronix.de; pbonzini@redhat.com; > >> sean.j.christopherson@intel.com; richardcochran@gmail.com; Mark > >> Rutland <Mark.Rutland@arm.com>; will@kernel.org; Suzuki Poulose > >> <Suzuki.Poulose@arm.com>; Steven Price <Steven.Price@arm.com>; > >> linux-kernel@vger.kernel.org; linux-arm- kernel@lists.infradead.org; > >> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper > >> <Steve.Capper@arm.com>; Kaly Xin <Kaly.Xin@arm.com>; Justin He > >> <Justin.He@arm.com>; nd <nd@arm.com> > >> Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64 > >> > >> Hi Jianyong, > >> > >> On 2020-01-10 10:15, Jianyong Wu wrote: > >> > Hi Marc, > >> > >> [...] > >> > >> >> >> > + ktime_overall = hvc_res.a0 << 32 | hvc_res.a1; > >> >> >> > + *ts = ktime_to_timespec64(ktime_overall); > >> >> >> > + *cycle = hvc_res.a2 << 32 | hvc_res.a3; > >> >> >> > >> >> >> So why isn't that just a read of the virtual counter, given > >> >> >> that what you do in the hypervisor seems to be "cntpct - cntvoff"? > >> >> >> > >> >> >> What am I missing here? > >> >> >> > >> >> > We need get clock time and counter cycle at the same time, so we > >> >> > can't just read virtual counter at guest and must get it from host. > >> >> > >> >> See my comment in my reply to patch #6: *Must* seems like a very > >> >> strong word, and you don't explain *why* that's better than just > >> >> computing the total hypercall cost. Hint: given the frequency of > >> >> the counter (in the few MHz > >> >> range) vs the frequency of a CPU (in the multiple GHz range, and > >> >> with an IPC close enough to 1), I doubt that you'll see the > >> >> counter making much progress across a hypercall. > >> >> > >> > Sorry, I will avoid to use those strong words. > >> > > >> > It's really the case that the hypercall won't across cycle in general. > >> > But sometimes, kernel preempt > >> > may happen in the middle of the hypercall which we can't assume how > >> > long before schedule back. so it's better capture them together at > >> > the same time. > >> > >> Fair enough. Please document the rational, as I guess others will ask > >> the same questions. > >> > > Ok > > > >> Then the problem to solve is that of the reference counter, as you so > >> far assume the virtual counter. I guess you need to be able to let > >> the guest select the reference counter when calling the PTP service. > >> > > I could not come up with an idea about the point where the guest give > > this info of counter value. > > Where we give that interface to ptp service, as it's not a user space > > application. > > Again: why don't you let the guest ask for the counter it wants as part of the > SMC call? What is preventing this? > Ok, let me try it
Thanks
> M. > -- > Jazz is not dead. It just smells funny...
| |