Messages in this thread | | | Date | Fri, 10 Jan 2020 10:35:02 +0000 | From | Marc Zyngier <> | 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.
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.
[...]
> By the way, does nested virtualization diff between arm64 and arm32?
There is no nested virt for 32bit (it is explicitly forbidden by the architecture).
M. -- Jazz is not dead. It just smells funny...
| |