Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64

Marc Zyngier
2020-01-10T10:35:09Z

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...