mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jacob Shin <jacob.shin@amd.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, <x86@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Jiri Olsa <jolsa@redhat.com>, <linux-kernel@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
Date: Sat, 27 Apr 2013 10:40:26 -0500	[thread overview]
Message-ID: <20130427154026.GA3529@jshin-Toonie> (raw)
In-Reply-To: <20130427150510.GA25109@redhat.com>

On Sat, Apr 27, 2013 at 05:05:10PM +0200, Oleg Nesterov wrote:
> On 04/26, Jacob Shin wrote:
> >
> > Implement hardware breakpoint address mask for AMD Family 16h and
> > above processors. CPUID feature bit indicates hardware support for
> > DRn_ADDR_MASK MSRs. These masks further qualify DRn/DR7 hardware
> > breakpoint addresses to allow matching of larger addresses ranges.
> 
> Imho, looks good.
> 
> Just one nit and one question below.
> 
> > @@ -163,29 +165,8 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
> >  	*dr7 &= ~__encode_dr7(i, info->len, info->type);
> ...
> > +	if (info->mask)
> > +		set_dr_addr_mask(0, i);
> 
> I agree we should clear addr_mask anyway.
> 
> But I am just curious, what if we do not? I mean what will the hardware
> do if this breakpoint was already disabled but the mask wasn't cleared?

Oh, it is fine if we don't and we are not using breakpoints, however I
was trying to account for per-thread events sharing the same DR
register, in that case we don't want previous event's mask value still
in the MSR.

So it was either clear on uninstall, or unconditionally set (even if
the new event's mask should be 0)

> 
> > @@ -314,11 +300,14 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
> >  	if (ret)
> >  		return ret;
> >  
> > -	ret = -EINVAL;
> > -
> >  	switch (info->len) {
> >  	case X86_BREAKPOINT_LEN_1:
> >  		align = 0;
> > +		if (info->mask) {
> > +			if (!cpu_has_bpext)
> > +				return -EOPNOTSUPP;
> > +			align = info->mask;
> 
> OK. But it seems we need a CONFIG_CPU_SUP_AMD-dependant helper for
> this cpu_has_bpext check? (like we have the nop set_dr_addr_mask()
> variant if !CONFIG_CPU_SUP_AMD).
> 
> Suppose that the kernel was compiled without CONFIG_CPU_SUP_AMD.
> Then perf_event_open(attr => { .bp_len == 16 }) will succeed, but
> this breakpoint won't actually work as expected?

Well, on non-AMD, even if we have CONFIG_CPU_SUP_AMD=y or not,
cpu_has_bpext (x86 CPUID check) will fail.

On AMD, if we don't have CONFIG_CPU_SUP_AMD=y then we can't even boot.
So I think ... its fine.


> 
> Oleg.
> 
> 


  parent reply	other threads:[~2013-04-27 15:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 18:57 [PATCH 0/3] perf/x86/amd: AMD Family 16h Data Breakpoint Extensions Jacob Shin
2013-04-26 18:57 ` [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8 Jacob Shin
2013-04-27 15:05   ` Oleg Nesterov
2013-04-27 15:14     ` Oleg Nesterov
2013-04-27 15:40     ` Jacob Shin [this message]
2013-04-27 16:10       ` Oleg Nesterov
2013-04-28  6:05         ` Jacob Shin
2013-04-26 18:57 ` [PATCH 2/3] perf tools: allow user to specify hardware breakpoint bp_len Jacob Shin
2013-04-27 16:58   ` Oleg Nesterov
2013-04-27 17:34     ` Oleg Nesterov
2013-04-28  5:44       ` Jacob Shin
2013-04-28  5:50     ` H. Peter Anvin
2013-04-28 16:12       ` Oleg Nesterov
2013-04-26 18:57 ` [PATCH 3/3] perf tools: add hardware breakpoint bp_len test cases Jacob Shin
2013-04-28  6:05 [PATCH V4 0/3] perf/x86/amd: AMD Family 16h Data Breakpoint Extensions Jacob Shin
2013-04-28  6:05 ` [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8 Jacob Shin
2013-10-02 16:11 [PATCH V5 0/3] perf/x86/amd: AMD Family 16h Data Breakpoint Extensions suravee.suthikulpanit
2013-10-02 16:11 ` [PATCH 1/3] perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8 suravee.suthikulpanit
2013-10-31  9:58   ` Frederic Weisbecker
2013-10-31 10:48     ` Borislav Petkov
2013-10-31 11:23       ` Frederic Weisbecker
2013-11-02  4:34         ` Borislav Petkov
2013-11-08 21:22           ` Suravee Suthikulpanit
2013-11-08 14:40             ` Borislav Petkov
2013-10-31 16:49     ` Oleg Nesterov
2013-11-08 19:41   ` Frederic Weisbecker
2013-11-09 15:11     ` Oleg Nesterov
2013-11-09 15:32       ` Frederic Weisbecker
2013-11-09 15:54         ` Oleg Nesterov
2013-11-11 15:44           ` Frederic Weisbecker
2013-11-11 17:51             ` Oleg Nesterov
2013-12-02 23:12               ` Frederic Weisbecker
2013-12-04 13:57                 ` Oleg Nesterov
2013-12-10 14:43                   ` Frederic Weisbecker
2013-12-10 14:52                   ` Frederic Weisbecker
2013-12-10 15:23   ` Frederic Weisbecker
2013-12-10 16:19     ` Oleg Nesterov
2013-12-10 16:30       ` Frederic Weisbecker
2013-12-11 12:05     ` Suravee Suthikulanit

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=20130427154026.GA3529@jshin-Toonie \
    --to=jacob.shin@amd.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.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

Powered by JetHome