Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4830072ybc; Fri, 15 Nov 2019 10:44:11 -0800 (PST) X-Google-Smtp-Source: APXvYqzQi0z1e8n/RGF7vVYjVWvDYN0FkZEq1j7Uh9HDVFywMRbYusEsGyW+28nX/WyiEWKSUUl4 X-Received: by 2002:a17:906:b80f:: with SMTP id dv15mr2985417ejb.188.1573843450992; Fri, 15 Nov 2019 10:44:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573843450; cv=none; d=google.com; s=arc-20160816; b=rgkbovql1Rbp/Bfe3b5uddw37M7HpIvEzo/hPupZhKE01NfqAqbSmnuzOl3asWA85L n/OWVDM5pV+3hTcOXBvoAsrFkFC1o0JlGzOVXPvTHTlbJd2UwTyVZ5vtNCsZTCbWQ38G ulCFrdu/kcsUcN74NH65la9vsJdRGJcCa/l0u1OFameNTeOkMUkBW4M00Ou1M0gCcywE CVmvxRJnl+/Im85m8EslITZxrsbensfRRdPwiawGm0IQhVBhvsYFD39lDjsqmWzzRlgE YGgg3Tbf/BQfspwd99fj/mN/ZigU7lwurkh2ILab+wHbkeG5npwKjUywPFXFx5ESxkDS zUqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=APYoFKU1VHCV5FDz+rQb9zTUb9MyLQea2oyOYCc2WDk=; b=nj02nte6Zg8x7yWCKHbiUGlzhlK5Gzxep+Bix4w9YxZ1N8w4giPNGSHHZJMBDmbYwo PfjAV+6lfjTwRv3U5c4nT93hhkcp5fEgzRCiwpz7ehG8VfEvcy//Ib1UrQ/419KE2mwg s1zn19hA0+gd1TYS2NavN76f6811sAFOmeM2QTQnvx3Y4P06pvz/s7WhvOG0TJqbAzxa g+1q/e+KbrVtSjRUIZVbdd6YC8Jn4wWpZBrhoiSrHH5ZCpzDHvBn9duvohieVJ1xJ5My YfLJByz+txvRoZp7MN7TByq3U4dhHAjZuVVoixgBjv6qeBKzBNnhDOaLk5edYutPP00g mK2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q8si6220634ejt.321.2019.11.15.10.43.44; Fri, 15 Nov 2019 10:44:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726549AbfKOSmo (ORCPT + 99 others); Fri, 15 Nov 2019 13:42:44 -0500 Received: from mga02.intel.com ([134.134.136.20]:40238 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726075AbfKOSmo (ORCPT ); Fri, 15 Nov 2019 13:42:44 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2019 10:42:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,309,1569308400"; d="scan'208";a="208210512" Received: from linux.intel.com ([10.54.29.200]) by orsmga003.jf.intel.com with ESMTP; 15 Nov 2019 10:42:43 -0800 Received: from [10.251.5.106] (kliang2-mobl.ccr.corp.intel.com [10.251.5.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id A97EF580472; Fri, 15 Nov 2019 10:42:42 -0800 (PST) Subject: Re: [PATCH] perf/x86/intel: Avoid PEBS_ENABLE MSR access in PMI To: Andi Kleen Cc: Peter Zijlstra , acme@redhat.com, mingo@kernel.org, linux-kernel@vger.kernel.org, eranian@google.com References: <20191115133917.24424-1-kan.liang@linux.intel.com> <20191115140739.GM4131@hirez.programming.kicks-ass.net> <3e117702-c07f-bd58-9931-766c2698b5d7@linux.intel.com> <20191115183341.GB22747@tassilo.jf.intel.com> From: "Liang, Kan" Message-ID: Date: Fri, 15 Nov 2019 13:42:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191115183341.GB22747@tassilo.jf.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/2019 1:33 PM, Andi Kleen wrote: >> @@ -2620,6 +2624,15 @@ static int handle_pmi_common(struct pt_regs *regs, >> u64 status) >> handled++; >> x86_pmu.drain_pebs(regs); >> status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI; >> + >> + /* >> + * PMI may land after cpuc->enabled=0 in x86_pmu_disable() >> and >> + * PMI throttle may be triggered for the PMI. >> + * For this rare case, intel_pmu_pebs_disable() will not >> touch >> + * MSR_IA32_PEBS_ENABLE. Explicitly disable the PEBS here. >> + */ >> + if (unlikely(!cpuc->enabled && !cpuc->pebs_enabled)) >> + wrmsrl(MSR_IA32_PEBS_ENABLE, 0); > > How does the enable_all() code know to reenable it in this case? For this case, we know that perf is disabling the PMU. The PMI handler will not restore PMU state when it's inactive. The enable_all() will not be called. Thanks, Kan