[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xen 4.14.3 incorrect (~3x) cpu frequency reported


  • To: James Dingwall <james-xen@xxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 10 Jan 2022 08:52:55 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zVxBFdh4/+pAhvi37FyS/Afmf7oZKerIuZhj4V0JYuk=; b=cnXZx5dOXoq2aSCyWKgNdiGa7x2PBUqEYeZY9+YGUG7Of3Au0C/bWYMl4YQa8OsN63bq1wyUXiue5mKd/MPf+DRdDpozeMyZX7GhOykvYrMpOwIQblhHppF2t274bF0+b2oNjHhfA5x6580TKPaimvYRnPlbJuiIp8Pr6nH4ClhhzMG8sMNJGkqnpVk0uAAdwiimot9llbXxJRj6NIZdHuHH4eAIIhvR2+tcprI/D6KMtFL0RvjilrIvJsVmMWuADE52/ySHjEKcQSLoy/EBGDHQfGAQl7pFbk4iPaqCWdaBVwwMKoSrC6yya4dRX+vPiOBvkX5gielT97vldSYDdA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dDkfvWj7tJ0HRjWJjL7uR5YFutQcHqS3Jxp1MR3EoL3y54as3E22tcF6UCc9QJxJDSZf9n6QWkHgxtr9GcFZjdsx6KVL9BdBJr4ITEv7dOzYDJ0JttV6NecmrsKOC9NQnYWCMFDCARTj+9aWurmuEkCbAupzXgYUfr6aRDXGTl0afHBIki+Wo43UsmPEVz8B3Qo+1hq56DrzMnajr1vT2Nt+kZNF/0EYw9d+7HTG5LYADTldW2AfDksR8FdklvKbDEXgQLE4dNweIFzCMoHZQ1sHx3m091N3cImuK+gtiu5V9632qEE9ydRLsonshURTFT3wYZS6gfL3atUsh7yV0A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: alexander.rossa@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 10 Jan 2022 07:53:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.