* in ARMv8 the Generic Timers are mandatory at the architectural/hardware level
* however the kernel folks do not want to guarantee that they are always exposed to userspace (they want the flexibility in future to disable the userspace access for possible errata workarounds on future boards/CPUs)
* the glibc change has been reverted upstream: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=33ef2f0c763b51e1df7896d7d39d585824558c75
So I'm closing this bug because QEMU's behaviour currently is fine. If the kernel folk define a hwcap for timer access we can consider both exposing the generic timers and setting the hwcap then. (Alternatively if we ever get round to defining a VDSO for QEMU linux-user mode we might want the timer access for that, as the kernel does.)
To summarise the situation here:
* in ARMv8 the Generic Timers are mandatory at the architectural/ hardware level /sourceware. org/git/ ?p=glibc. git;a=commitdif f;h=33ef2f0c763 b51e1df7896d7d3 9d585824558c75
* however the kernel folks do not want to guarantee that they are always exposed to userspace (they want the flexibility in future to disable the userspace access for possible errata workarounds on future boards/CPUs)
* the glibc change has been reverted upstream: https:/
So I'm closing this bug because QEMU's behaviour currently is fine. If the kernel folk define a hwcap for timer access we can consider both exposing the generic timers and setting the hwcap then. (Alternatively if we ever get round to defining a VDSO for QEMU linux-user mode we might want the timer access for that, as the kernel does.)