Re: [PATCH 6/6] aarch64: Add hp-timing.h

[Catalin Marinas <catalin dot marinas at arm dot com>]

Hi Marcus,

On Thu, Sep 03, 2015 at 02:17:16PM +0100, Marcus Shawcroft wrote:
> On 22 June 2015 at 08:08, Andrew Pinski <pinskia@gmail.com> wrote:
> > On Sat, Jun 20, 2015 at 8:09 PM,  <pinskia@gmail.com> wrote:
> >>> I was updating the HP_TIMING code for RHEL7 and noticed AArch64
> >>> still lacks HP_TIMING support.
> >>
> >> Doesn't the server standard for armv8 require gti?  If so we can
> >> declare the standard glibc only for server base standard. And have
> >> an option later on for the other base standards.

I'm definitely against glibc flavours based on whether it's server or
mobile. And SBSA is just a recommendation, not some enforced standard.

> > The answer to my question is yes it is a requirement for Server Base
> > System Architecture Level 0 which means all server class systems have
> > it.  It also means nobody is not going to implement one processor
> > without GTI that is also going to use glibc.  So I think we should
> > just enable it by default for glibc and then when the day comes (if it
> > comes but I doubt it) have an option to disable the support for the
> > virtual timer.
> 
> The "optionality" argument against the use on cntvct_el0 no longer
> holds,  the  ARMv8-A Reference Manual Issue >= A.d does not describe
> the generic timer as optional.  The other  remaining issue is whether
> the kernel  exposes  cntvct_el0 to user space for general use or
> whether that register is considered to be exposed for the benefit of
> the VDSO only.

The ARM ARM may mandate the presence of the CNTVCT_EL0 register (IOW it
won't undef when read) but to be of any use it also needs to be wired up
on the SoC so that it counts something. That's outside the scope of the
ARM ARM, so we cannot guarantee this (it may simply be a case of
hardware bugs where the counter is not the same on all CPUs, so we
better disable it altogether; we've seen this before).

What are the glibc expectations here for HP_TIMING? Is it fine if it
always returns 0? Does its frequency need to be known? If yes, how do we
expose such frequency to user space?

> There are two ways forward:
> 
> 1) Kernel folk agree to expose cntvct_el0 for the benefit of general
> user space.

See above.

> 2) We add a HWCAP bit to indicate if cntvct_el0 is exposed.

And who's going to check this bit? From my experience, we had HWCAP_SWP
before, we removed it but no-one was checking it so we had to emulate
the instruction.

IIUC here it's a simple HP_TIMING_NOW macro which translates to an mrs.
Do you plan to add further checks for HWCAP here?

> Taking the proposed patch as it stands in the absence of a commitment
> from the kernel doesn't look sensible to me.  Since the loader uses hp
> timers in normal operation we will end up with a dynamic loader that
> faults if a future kernel disables visibility of cntvct_el0.

Is exposing a reader function via VDSO be feasible here? Or it's too
early for the dynamic loader?

-- 
Catalin