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
