[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: xen 4.14.3 incorrect (~3x) cpu frequency reported
On 07.01.2022 12:39, Jan Beulich wrote: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -378,8 +378,9 @@ static u64 read_hpet_count(void) > > static int64_t __init init_hpet(struct platform_timesource *pts) > { > - uint64_t hpet_rate, start; > + uint64_t hpet_rate, start, expired; > uint32_t count, target; > +unsigned int i;//temp > > if ( hpet_address && strcmp(opt_clocksource, pts->id) && > cpuidle_using_deep_cstate() ) > @@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p > > pts->frequency = hpet_rate; > > +for(i = 0; i < 16; ++i) {//temp > count = hpet_read32(HPET_COUNTER); > start = rdtsc_ordered(); > target = count + CALIBRATE_VALUE(hpet_rate); > if ( target < count ) > while ( hpet_read32(HPET_COUNTER) >= count ) > continue; > - while ( hpet_read32(HPET_COUNTER) < target ) > + while ( (count = hpet_read32(HPET_COUNTER)) < target ) > continue; Unlike I first thought but matching my earlier reply, this only reduces the likelihood of encountering an issue. In particular, a long-duration event ahead of the final HPET read above would be covered, but ... > - return (rdtsc_ordered() - start) * CALIBRATE_FRAC; > + expired = rdtsc_ordered() - start; ... such an event occurring between the final HPET read and the TSC read would still be an issue. So far I've only been able to think of an ugly way to further reduce likelihood for this window, but besides that neither being neat nor excluding the possibility altogether, I have to point out that we have the same issue in a number of other places: Back-to-back reads of platform timer and TSC are assumed to happen close together elsewhere as well. Cc-ing other x86 maintainers to see whether they have any helpful thoughts ... Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |