Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753565AbbG2INx (ORCPT ); Wed, 29 Jul 2015 04:13:53 -0400 Received: from mgwym02.jp.fujitsu.com ([211.128.242.41]:61346 "EHLO mgwym02.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbbG2INr (ORCPT ); Wed, 29 Jul 2015 04:13:47 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2 Subject: Re: [PATCH RFC 2/3] x86: Add Intel PT logger To: , , , , , , References: <1438145496-5932-1-git-send-email-indou.takao@jp.fujitsu.com> <1438145496-5932-3-git-send-email-indou.takao@jp.fujitsu.com> <876153binx.fsf@ashishki-desk.ger.corp.intel.com> From: Takao Indoh CC: , Message-ID: <55B88B20.4020707@jp.fujitsu.com> Date: Wed, 29 Jul 2015 17:13:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <876153binx.fsf@ashishki-desk.ger.corp.intel.com> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3205 Lines: 102 On 2015/07/29 15:08, Alexander Shishkin wrote: > Takao Indoh writes: > >> This patch provides Intel PT logging feature. When system boots with a >> parameter "intel_pt_log", log buffers for Intel PT are allocated and >> logging starts, then processor flow information is written in the log >> buffer by hardware like flight recorder. This is very helpful to >> investigate a cause of kernel panic. >> >> The log buffer size is specified by the parameter >> "intel_pt_log_buf_len=". This buffer is used as circular buffer, >> therefore old events are overwritten by new events. > > [skip] > >> +static void enable_pt(int enable) >> +{ >> + u64 ctl; >> + >> + rdmsrl(MSR_IA32_RTIT_CTL, ctl); > > Ideally, you shouldn't need this rdmsr(), because in this code you > should know exactly which ctl bits you need set when you enable. I see, I'll remove this rdmsr in next version. > >> + >> + if (enable) >> + ctl |= RTIT_CTL_TRACEEN; >> + else >> + ctl &= ~RTIT_CTL_TRACEEN; >> + >> + wrmsrl(MSR_IA32_RTIT_CTL, ctl); >> +} > > But the bigger problem with this approach is that it duplicates the > existing driver's functionality and some of the code, which just makes > it harder to maintain amoung other things. > > Instead, we should be able to do use the existing perf functionality to > enable the system-wide tracing, so that it goes through the "existing driver" means PMU driver (perf_event_intel_pt.c)? The feature of these patches is a sort of flight recorder. Once it starts, never stop, not export anything to user, it just captures data with minimum overhead in preparation for kernel panic. This usage is different from perf and therefore I'm not sure whether this feature can be implemented using perf infrastructure. > driver. Another thing to remember is that you'd also need some of the > sideband data (vm mappings, context switches) to be able to properly > decode the trace, which also can come from perf. And it'd also be much > less code. The only missing piece is the code that would allocate the > ring buffer for such events. The sideband data is needed if we want to reconstruct user program flow, but is it needed to reconstruct kernel panic path? Thanks, Takao Indoh > > Something like: > > static DEFINE_PER_CPU(struct perf_event *, perf_kdump_event); > > static struct perf_event_attr perf_kdump_attr; > > ... > > static int perf_kdump_init(void) > { > struct perf_event *event; > int cpu; > > get_online_cpus(); > for_each_possible_cpu(cpu) { > event = perf_create_kernel_counter(&perf_kdump_attr, > cpu, NULL, > NULL, NULL); > > ... > > ret = rb_alloc_kernel(event, perf_kdump_data_size, perf_kdump_aux_size); > > ... > > per_cpu(perf_kdump_event, cpu) = event; > } > put_online_cpus(); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/