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

Re: [PATCH] x86/Intel: don't log bogus frequency range on Core/Core2 processors


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 8 Feb 2022 11:51:03 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=cVKN6yO42bbFFeWXodLK+XrYr1FH55QB74wAca7cttc=; b=cn7WZzNfZ2qYjpO88qs5ZeboyVzjzNwibaV/dkAxA6JE8argTvNjNRPpx2MLKPT+YLs9F4TkxtWskOP+u/y+6zrSpWlFHsKQze1bDFJaVHvr+JokEDu2CyNBXQLQOBSh1CX5SRMO4OnEeydMlLPglsP/X/Xlkcpk1HIbccaBdzZkhwlPBlbpTz7+sSUftAjNaBiuRIFmzqdFGBUj7DbBc3bGwJlP30qpkxoXHdPqn6cZYqO1jssBcYnhPNGqbofAl4jNiZmUJk7SUf/5I9p83vPP4xY0VFED9QEOAbsk4QE9V2mcmzPlDa5vU9dcAG4p/BoLDGPw3faj4wY/sh/ggg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MNZiTbTuTBDIpLD+0VNYgHGSwHId3lp/ZeTt2vSOWLAkektcx/DpmDhzaYm1zhBbvlfB1QNBifi6Ruf0JcMqyAPnZneCY2iUeDg/ZqWb/yMCcwkFSwK1ivswmI72HuvYcipGc25qEL5BB2gW6SpGRvkdsfG2hQcvLjstSxjI6x7CMIdskbxgnZPw6aPmhXeaZvR3HH2raD7yT9eav3ePB8vy8XMh2IIEH4rXYvjPSZeJxMKL2uPVSPp+/iDNFyPQ7gkjXesmDm8BesFVsiBG3r3RsWkzf1Ti508VwhR+cjapILAo4SluEBNGB1aL0/8ooWHWENjYy7vw/Y2Z29rZXQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 08 Feb 2022 10:51:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.02.2022 09:54, Roger Pau Monné wrote:
> On Fri, Feb 04, 2022 at 02:56:43PM +0100, Jan Beulich wrote:
>> Models 0F and 17 don't have PLATFORM_INFO documented. While it exists on
>> at least model 0F, the information there doesn't match the scheme used
>> on newer models (I'm observing a range of 700 ... 600 MHz reported on a
>> Xeon E5345).
> 
> Maybe it would be best to limit ourselves to the models that have the
> MSR documented in the SDM?

Well, yes, that's what I wasn't sure about: The information is used only
for logging, so it's not the end of the world if we display something
strange. We'd want to address such anomalies (like the one I did observe
here) of course. But I wonder whether being entirely silent is really
better.

>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -435,6 +435,26 @@ static void intel_log_freq(const struct
>>          if ( c->x86 == 6 )
>>              switch ( c->x86_model )
>>              {
>> +                static const unsigned short core_factors[] =
>> +                    { 26667, 13333, 20000, 16667, 33333, 10000, 40000 };
>> +
>> +            case 0x0e: /* Core */
>> +            case 0x0f: case 0x16: case 0x17: case 0x1d: /* Core2 */
>> +                /*
>> +                 * PLATFORM_INFO, while not documented for these, appears to
>> +                 * exist in at least some cases, but what it holds doesn't
>> +                 * match the scheme used by newer CPUs.  At a guess, the min
>> +                 * and max fields look to be reversed, while the scaling
>> +                 * factor is encoded in FSB_FREQ.
>> +                 */
>> +                if ( min_ratio > max_ratio )
>> +                    SWAP(min_ratio, max_ratio);
>> +                if ( rdmsr_safe(MSR_FSB_FREQ, msrval) ||
>> +                     (msrval &= 7) >= ARRAY_SIZE(core_factors) )
>> +                    return;
>> +                factor = core_factors[msrval];
>> +                break;
>> +
>>              case 0x1a: case 0x1e: case 0x1f: case 0x2e: /* Nehalem */
>>              case 0x25: case 0x2c: case 0x2f: /* Westmere */
>>                  factor = 13333;
> 
> Seeing that the MSR is present on non documented models and has
> unknown behavior we might want to further sanity check that min < max
> before printing anything?

But I'm already swapping the two in the opposite case?

Jan




 


Rackspace

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