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

[Marcus Shawcroft <marcus dot shawcroft at gmail dot com>]

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:
>>
>>
>>
>>
>>> On Jun 20, 2015, at 7:20 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>
>>>> On 07/21/2014 02:31 PM, Marcus Shawcroft wrote:
>>>>> On 21 July 2014 13:01, Andreas Schwab <schwab@suse.de> wrote:
>>>>> pinskia@gmail.com writes:
>>>>>
>>>>>>> On Jul 21, 2014, at 4:41 AM, Andreas Schwab <schwab@suse.de> wrote:
>>>>>>>
>>>>>>> Richard Henderson <rth@twiddle.net> writes:
>>>>>>>
>>>>>>>> +/* Sync the instruction stream, and read from the virtual cycle counter.  */
>>>>>>>> +#define HP_TIMING_NOW(Var) \
>>>>>>>> +  __asm__ __volatile__ ("isb; mrs %0, cntvct_el0" : "=r" (Var))
>>>>>>>
>>>>>>> According to https://bugs.launchpad.net/bugs/1344320 the generic timers
>>>>>>> are not part of the kernel-to-userspace contract.
>>>>>>
>>>>>>
>>>>>> I think this is bogus for the kernel folks not allow a high
>>>>>> precision timer in user space. Timers like this are needed for
>>>>>> micro-benchmarking compiler changes along with other libc
>>>>>> changes.
>>>>>
>>>>> According to the qemu bug the timers are optional.
>>>>
>>>> The generic timers are indeed optional, therefore we should not assume
>>>> they are always present.  I don't want this to ship in 2.20 as is, so
>>>> will back out the patch in the morning pending a better solution.
>>>
>>> Any solution for this yet?
>>>
>>> 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.
>
> 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.

There are two ways forward:

1) Kernel folk agree to expose cntvct_el0 for the benefit of general user space.

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

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.

Catalin could you comment on options 1) and 2) above ?

Cheers
/Marcus