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

[Marc Zyngier]

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