[PATCH v4 03/28] KVM: arm64: pkvm: Add pkvm_time_get()

[Marc Zyngier]

On Tue, 09 Sep 2025 15:16:26 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> On Tue, Aug 19, 2025 at 09:51:31PM +0000, Mostafa Saleh wrote:
> > Add a function to return time in us.
> > 
> > This can be used from IOMMU drivers while waiting for conditions as
> > for SMMUv3 TLB invalidation waiting for sync.
> > 
> > Signed-off-by: Mostafa Saleh <smostafa at google.com>
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
> > ---
> >  arch/arm64/kvm/hyp/include/nvhe/pkvm.h |  2 ++
> >  arch/arm64/kvm/hyp/nvhe/setup.c        |  4 ++++
> >  arch/arm64/kvm/hyp/nvhe/timer-sr.c     | 33 ++++++++++++++++++++++++++
> >  3 files changed, 39 insertions(+)

[...]

> > +#define SEC_TO_US 1000000
> > +
> > +int pkvm_timer_init(void)
> > +{
> > +	timer_freq = read_sysreg(cntfrq_el0);
> > +	/*
> > +	 * TODO: The highest privileged level is supposed to initialize this
> > +	 * register. But on some systems (which?), this information is only
> > +	 * contained in the device-tree, so we'll need to find it out some other
> > +	 * way.
> > +	 */
> > +	if (!timer_freq || timer_freq < SEC_TO_US)
> > +		return -ENODEV;
> > +	return 0;
> > +}
> 
> Right, I think the frequency should be provided by the host once the arch
> timer driver has probed successfully. Relying on CNTFRQ isn't viable imo.

We can always patch the value in, à la kimage_voffset. But it really
begs the question: who is their right mind doesn't set CNTFRQ_EL0 to
something sensible? Why should we care about supporting such
contraption?

I'd be happy to simply disable KVM when CNTFRQ_EL0 is misprogrammed,
or that the device tree provides a clock frequency. Because there is
no good way to support a guest in that case.

	M.

-- 
Without deviation from the norm, progress is not possible.