1ed95e52d9
Allowing user code to map the HPET is problematic. HPET implementations are notoriously buggy, and there are probably many machines on which even MMIO reads from bogus HPET addresses are problematic. We have a report that the Dell Precision M2800 with: ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL CBX3 01072009 AMI. 00000005) is either so slow when accessing the HPET or actually hangs in some regard, causing soft lockups to be reported if users do unexpected things to the HPET. The vclock HPET code has also always been a questionable speedup. Accessing an HPET is exceedingly slow (on the order of several microseconds), so the added overhead in requiring a syscall to read the HPET is a small fraction of the total code of accessing it. To avoid future problems, let's just delete the code entirely. In the long run, this could actually be a speedup. Waiman Long as a patch to optimize the case where multiple CPUs contend for the HPET, but that won't help unless all the accesses are mediated by the kernel. Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andy Lutomirski <luto@kernel.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Waiman Long <Waiman.Long@hpe.com> Cc: Waiman Long <waiman.long@hpe.com> Link: http://lkml.kernel.org/r/d2f90bba98db9905041cff294646d290d378f67a.1460074438.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
16 lines
387 B
C
16 lines
387 B
C
/* x86-specific clocksource additions */
|
|
|
|
#ifndef _ASM_X86_CLOCKSOURCE_H
|
|
#define _ASM_X86_CLOCKSOURCE_H
|
|
|
|
#define VCLOCK_NONE 0 /* No vDSO clock available. */
|
|
#define VCLOCK_TSC 1 /* vDSO should use vread_tsc. */
|
|
#define VCLOCK_PVCLOCK 2 /* vDSO should use vread_pvclock. */
|
|
#define VCLOCK_MAX 2
|
|
|
|
struct arch_clocksource_data {
|
|
int vclock_mode;
|
|
};
|
|
|
|
#endif /* _ASM_X86_CLOCKSOURCE_H */
|