Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0e3b3e6e-53b9-b426-71cd-911d3ecbfc24@linux.intel.com>
Date:   Tue, 12 Jul 2022 19:08:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.0.1
Subject: Re: [perf] unchecked MSR access error: WRMSR to 0x689 in
 intel_pmu_lbr_restore
Content-Language: en-US
To:     Vince Weaver <vincent.weaver@maine.edu>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>
References: <66961a7d-a6d8-2536-9ed3-68c2e7f4e03d@maine.edu>
 <e71fa75-a718-ffb-c3f3-40cccf77ba9b@maine.edu>
 <4b15d3d1-389b-fee4-d1b9-8732859e3696@linux.intel.com>
 <20220711221658.4gpkizopmftpnav6@guptapa-desk>
 <32ccdda1-63bf-746e-48fb-935fa58285b1@maine.edu>
 <20220712204830.kvblayj37s3udt4b@guptapa-desk>
 <487465e6-b034-f08-907-de37a0a173b5@maine.edu>
From:   "Liang, Kan" <kan.liang@linux.intel.com>
In-Reply-To: <487465e6-b034-f08-907-de37a0a173b5@maine.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2022-07-12 5:26 p.m., Vince Weaver wrote:
> On Tue, 12 Jul 2022, Pawan Gupta wrote:
> 
>> On Tue, Jul 12, 2022 at 03:39:56PM -0400, Vince Weaver wrote:
>> It appears this CPU does not support TSX feature (or disabling TSX). If
>> the bug is easy to reproduce, bisecting can help.
> 
> I thought TSX was disabled via firmware update for all Haswell machines?
> 
> In any case, the fuzzer is triggering the
> 	unchecked MSR access error: WRMSR to 0x689
> in intel_pmu_lbr_restore.  So either this is a false error and should be 
> disabled, or else it's a real issue and should be fixed.
> 

Could you please double check if the quirk can fix the issue on your
machine?

#Try write the exact same value from the error log to 0x689. The write
should fail.
wrmsr -p 0 0x689 0x1fffffff8101349e

#The quirk copy bits 59:60 to bits 61:62. The below write should succeed.
wrmsr -p 0 0x689 0x7fffffff8101349e

> Unfortunately the fuzzer can take up to a few days to trigger the message 
> (it's not easily repeatable) so doing a kernel bisect would take a very 
> long time.
> 

The lbr_from_signext_quirk_needed() is only invoked at boot time. Maybe
we can dump some logs to understand which variable is not expected.

Could you please apply the below patch, reboot to the patched kernel and
share the dmesg log?

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 13179f31fe10..50435ab627ad 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -300,6 +300,9 @@ static inline bool lbr_from_signext_quirk_needed(void)
 	bool tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
 			   boot_cpu_has(X86_FEATURE_RTM);

+	pr_info("%s %s. LBR has tsx %d\n", boot_cpu_has(X86_FEATURE_HLE) ?
"HLE" : "NO HLE",
+			boot_cpu_has(X86_FEATURE_RTM) ? "RTM" : "NO RTM",
+			x86_pmu.lbr_has_tsx);
 	return !tsx_support && x86_pmu.lbr_has_tsx;
 }


Thanks,
Kan