[RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
maz at kernel.org
Fri Jan 10 02:35:02 PST 2020
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
>> word, and you don't explain *why* that's better than just computing
>> 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
>> 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
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
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel