All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takao Indoh <indou.takao@jp.fujitsu.com>
To: <alexander.shishkin@linux.intel.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: Wed, 9 Sep 2015 11:40:22 +0900	[thread overview]
Message-ID: <55EF9C16.1040301@jp.fujitsu.com> (raw)
In-Reply-To: <87oahdfdhl.fsf@ashishki-desk.ger.corp.intel.com>

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.

Thanks,
Takao Indoh


> 
> Thanks,
> --
> Alex
> 



  reply	other threads:[~2015-09-09  2:40 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 [this message]
2015-09-15 12:01       ` Alexander Shishkin
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=55EF9C16.1040301@jp.fujitsu.com \
    --to=indou.takao@jp.fujitsu.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.