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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux