This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/6] aarch64: Add hp-timing.h
- From: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, catalin dot marinas at arm dot com
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>, Richard Henderson <rth at twiddle dot net>, "azanella at linux dot vnet dot ibm dot com" <azanella at linux dot vnet dot ibm dot com>, "davem at davemloft dot net" <davem at davemloft dot net>, "marcus dot shawcroft at arm dot com" <marcus dot shawcroft at arm dot com>, Andrew Pinski <pinskia at gmail dot com>, peter dot maydell at linaro dot org, Szabolcs dot Nagy at arm dot com
- Date: Thu, 3 Sep 2015 14:17:16 +0100
- Subject: Re: [PATCH 6/6] aarch64: Add hp-timing.h
- Authentication-results: sourceware.org; auth=none
- References: <1403735086-21797-1-git-send-email-rth at twiddle dot net> <1403735086-21797-7-git-send-email-rth at twiddle dot net> <mvmd2czlz0k dot fsf at hawking dot suse dot de> <812AFAEE-C8E5-4583-8647-7E5ABE02F95C at gmail dot com> <mvm4myanco3 dot fsf at hawking dot suse dot de> <CAFqB+PyCXom3fqF8A=C10jV9syUeRmOg-JuTL1pxtVnLsgfj7A at mail dot gmail dot com> <55861F56 dot 1030506 at redhat dot com> <89431F96-326C-4054-B2D6-17863543CC9B at gmail dot com> <CA+=Sn1kZL8xmCPtzpULRMNQ7ommN6FxRmAQJVy2LV+wOF+WSkQ at mail dot 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