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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 12 Jan 2022 17:55:39 +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=1DYmNvI4f+mYibA77KNmzj3fgj0ASZ8x+uPhAeOnBio=; b=T7igKuxzuW4za4dhC7ZJDMDlBjkKVDD0NW0P48YTtdfFoqoMgUEOXXAxpcW9UDMM0KGV81eETdmpe77phLC4j4Zi+0VzXH0Z+uFFiuisLtkcgKDt1uJsQP+/I5kfZT2cyN7YpgnjJt/0iJ89tNfR1eLMsAX9QhpLmknv3Gwb3odQS0ImJVtBs36oeGOGHXFFB2BYzq+MLibX048i0MyCPteT01xdB9s6+Yg2YkOqo9rSzCXq/SkVYjICPJhi+ycPFYgybGZOQC7FVbIQJq2Nf6NK4VecYBETNm1R5ZgbtEVz2YsTXWLnDl+2XcA6irmt/L+qa5ttMU+F81YvapepEw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UR2R7ZT5cVguHQ3CbFTC3kNXI+k3b9kooqfyWzZVie0BZk49hXc0cFIE00ofXq9qQeojfKY9SXIk/CYfEC8E2UsSBBcn3vgiMjQTuRIF0/BsV91NUs3Og7UF0NJqjVuOJSD0iusNj2+jb21j59rLd3Y0bhSsLMz+lTO0Bxlr/JePTkZEyWl5+3xvxUcRYz7OTthqJWG/LhleMxpqhtP1sXB3sdmgYthdUq7Y+MI8fJGpPRFIZ8NWsUQ/ef6NGeP9NaryMIdoyuPt3FrS0UESL4aftS2s38V3wk4AXSgRDlulmtRB5+wY179AWmOoe7dq66MnfUkkgn3ZtkPnOtVUOQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: James Dingwall <james-xen@xxxxxxxxxxxxxx>, alexander.rossa@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 12 Jan 2022 16:56:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.01.2022 13:37, Roger Pau Monné wrote:
> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>> @@ -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;
>>  
>> -    return (rdtsc_ordered() - start) * CALIBRATE_FRAC;
>> +    expired = rdtsc_ordered() - start;
> 
> There's also a window between the HPET read and the TSC read where an
> SMI/NMI could cause a wrong frequency detection.

It occurred to me only while preparing a draft change that this is an
issue not only for the tail pair of reads, but also for the initial pair.
Hence I'm now actually making a helper function to be used in both
places. This slightly sub-optimal as it means that it's not as easy to
make use of the last HPET read in the loop above, but I guess we can
tolerate that one extra read in preference over more complicated logic.

Jan




 


Rackspace

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