From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Takao Indoh <indou.takao@jp.fujitsu.com>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
a.p.zijlstra@chello.nl, acme@kernel.org, vgoyal@redhat.com,
rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v2 3/4] perf/x86/intel/pt: Add Intel PT logger
Date: Tue, 15 Sep 2015 15:01:01 +0300 [thread overview]
Message-ID: <87d1xjnb7m.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <55EF9C16.1040301@jp.fujitsu.com>
Takao Indoh <indou.takao@jp.fujitsu.com> writes:
> On 2015/09/08 18:48, Alexander Shishkin wrote:
>> Takao Indoh <indou.takao@jp.fujitsu.com> writes:
>>
>>> +/* intel_pt */
>>> +static struct perf_event_attr pt_attr_pt = {
>>> + .config = 0x400, /* bit10: TSCEn */
>>
>> Doesn't it make sense to make these things configurable via sysfs or
>> whatnot?
>
> That make sense, will do.
>
>>
>>> +static int pt_log_buf_nr_pages = 128; /* number of pages for log buffer */
>>
>> Same here.
>>
>>> +static struct cpumask pt_log_cpu_mask;
>>> +
>>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_pt);
>>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_sched);
>>> +static DEFINE_PER_CPU(struct perf_event *, pt_perf_event_dummy);
>>> +
>>> +/* Saved registers on panic */
>>> +static DEFINE_PER_CPU(u64, saved_msr_ctl);
>>> +static DEFINE_PER_CPU(u64, saved_msr_status);
>>> +static DEFINE_PER_CPU(u64, saved_msr_output_base);
>>> +static DEFINE_PER_CPU(u64, saved_msr_output_mask);
>>> +
>>> +void save_intel_pt_registers(void)
>>> +{
>>> + int cpu = smp_processor_id();
>>> + u64 ctl;
>>> +
>>> + if (!cpumask_test_cpu(cpu, &pt_log_cpu_mask))
>>> + return;
>>> +
>>> + /* Save RTIT_CTL register */
>>> + rdmsrl(MSR_IA32_RTIT_CTL, ctl);
>>> + per_cpu(saved_msr_ctl, cpu) = ctl;
>>> +
>>> + /* Stop tracing */
>>> + ctl &= ~RTIT_CTL_TRACEEN;
>>> + wrmsrl(MSR_IA32_RTIT_CTL, ctl);
>>> +
>>> + /* Save other registers */
>>> + rdmsrl(MSR_IA32_RTIT_STATUS, per_cpu(saved_msr_status, cpu));
>>> + rdmsrl(MSR_IA32_RTIT_OUTPUT_BASE, per_cpu(saved_msr_output_base, cpu));
>>> + rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, per_cpu(saved_msr_output_mask, cpu));
>>
>> I'd really like to keep the PT msr accesses confined to the intel_pt
>> driver. Maybe have a similar function there? That way you could also use
>> pt_config_start() instead of clearing TraceEn by hand.
>>
>> Do you need these saved msr values for the crash tool? I'm guessing
>> you'd need the write pointer to figure out where the most recent data
>> is. But then again, if you go the perf_event_disable() path, it'll all
>> happen automatically in the driver. Or rather __perf_event_disable()
>> type of thing since this is strictly cpu-local. Or even
>> event::pmu::stop() would do the trick. The buffer's write head would
>> then be in this_cpu_ptr(&pt_ctx)->handle.head.
>
> Yes, what I need is the last position where Intel PT hardware wrote
> data. Once kernel panic occurs, basically we should minimize the access
> to kernel data or functions because they may be broken. That is why I
> touch msr directly in this patch. But I agree to limit the access to msr
> except intel_pt driver. Using pmu.stop() or pt_event_stop() looks good
> to me.
Ok, thanks!
Regards,
--
Alex
next prev parent reply other threads:[~2015-09-15 12:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 5:49 [PATCH v2 0/4] x86: Intel Processor Trace Logger Takao Indoh
2015-09-08 5:49 ` [PATCH v2 1/4] perf/trace: Add function to find event type by name Takao Indoh
2015-09-08 5:49 ` [PATCH v2 2/4] perf: Add function to enable perf events in kernel with ring buffer Takao Indoh
2015-09-08 9:32 ` Alexander Shishkin
2015-09-09 2:10 ` Takao Indoh
2015-09-15 12:00 ` Alexander Shishkin
2015-09-08 5:49 ` [PATCH v2 3/4] perf/x86/intel/pt: Add Intel PT logger Takao Indoh
2015-09-08 9:48 ` Alexander Shishkin
2015-09-09 2:40 ` Takao Indoh
2015-09-15 12:01 ` Alexander Shishkin [this message]
2015-09-08 5:49 ` [PATCH v2 4/4] x86: Stop Intel PT and save its registers when panic occurs Takao Indoh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1xjnb7m.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=hpa@zytor.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®