On 12/10/2013 9:23 AM, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500,suravee.suthikulpa...@amd.com wrote:
From: Jacob Shin
Implement hardware breakpoint address mask for AMD Family 16h and
above processors. CPUID feature bit indicates hardware support for
DRn_ADDR_MASK
On 12/10/2013 9:23 AM, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500,suravee.suthikulpa...@amd.com wrote:
From: Jacob Shinjacob.w.s...@gmail.com
Implement hardware breakpoint address mask for AMD Family 16h and
above processors. CPUID feature bit indicates hardware
On Tue, Dec 10, 2013 at 05:19:45PM +0100, Oleg Nesterov wrote:
> On 12/10, Frederic Weisbecker wrote:
> >
> > On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com
> > wrote:
> > > @@ -279,7 +260,16 @@ static int arch_build_bp_info(struct perf_event *bp)
> > > }
> > >
> > >
On 12/10, Frederic Weisbecker wrote:
>
> On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> > @@ -279,7 +260,16 @@ static int arch_build_bp_info(struct perf_event *bp)
> > }
> >
> > /* Len */
> > + info->mask = 0;
> > +
> > switch (bp->attr.bp_len) {
> >
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Jacob Shin
>
> 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
On Wed, Dec 04, 2013 at 02:57:43PM +0100, Oleg Nesterov wrote:
> > Ideally it would be nice if we drop bp_mask and use extended ranges
> > only when len > 8. How does that sound?
>
> Again, iirc, this is what the code does. except (in essence) it checks
> mask != 0 instead of len > 8.
>
> And
On Wed, Dec 04, 2013 at 02:57:43PM +0100, Oleg Nesterov wrote:
> On 12/03, Frederic Weisbecker wrote:
> >
> > 2013/11/11 Oleg Nesterov :
> > > On 11/11, Frederic Weisbecker wrote:
> > >>
> > >> On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
> > >> >
> > >> > Up to you and Suravee,
On Wed, Dec 04, 2013 at 02:57:43PM +0100, Oleg Nesterov wrote:
On 12/03, Frederic Weisbecker wrote:
2013/11/11 Oleg Nesterov o...@redhat.com:
On 11/11, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Up to you and Suravee, but can't
On Wed, Dec 04, 2013 at 02:57:43PM +0100, Oleg Nesterov wrote:
Ideally it would be nice if we drop bp_mask and use extended ranges
only when len 8. How does that sound?
Again, iirc, this is what the code does. except (in essence) it checks
mask != 0 instead of len 8.
And yes, we can
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
From: Jacob Shin jacob.w.s...@gmail.com
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
On 12/10, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
@@ -279,7 +260,16 @@ static int arch_build_bp_info(struct perf_event *bp)
}
/* Len */
+ info-mask = 0;
+
switch (bp-attr.bp_len) {
+ default:
+
On Tue, Dec 10, 2013 at 05:19:45PM +0100, Oleg Nesterov wrote:
On 12/10, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com
wrote:
@@ -279,7 +260,16 @@ static int arch_build_bp_info(struct perf_event *bp)
}
/* Len */
+
On 12/03, Frederic Weisbecker wrote:
>
> 2013/11/11 Oleg Nesterov :
> > On 11/11, Frederic Weisbecker wrote:
> >>
> >> On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
> >> >
> >> > Up to you and Suravee, but can't we cleanup this later?
> >> >
> >> > This series was updated many
On 12/03, Frederic Weisbecker wrote:
2013/11/11 Oleg Nesterov o...@redhat.com:
On 11/11, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Up to you and Suravee, but can't we cleanup this later?
This series was updated many times to
2013/11/11 Oleg Nesterov :
> On 11/11, Frederic Weisbecker wrote:
>>
>> On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
>> >
>> > Up to you and Suravee, but can't we cleanup this later?
>> >
>> > This series was updated many times to address a lot of (sometimes
>> > contradictory)
2013/11/11 Oleg Nesterov o...@redhat.com:
On 11/11, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Up to you and Suravee, but can't we cleanup this later?
This series was updated many times to address a lot of (sometimes
contradictory)
On 11/11, Frederic Weisbecker wrote:
>
> On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
> >
> > Up to you and Suravee, but can't we cleanup this later?
> >
> > This series was updated many times to address a lot of (sometimes
> > contradictory) complaints.
>
> Sure. But I'm
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
> Just in case let me repeat, I can be easily wrong because I forgot
> how this series actually look and I don't have the patches now ;)
>
> On 11/09, Frederic Weisbecker wrote:
> >
> > On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Just in case let me repeat, I can be easily wrong because I forgot
how this series actually look and I don't have the patches now ;)
On 11/09, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov
On 11/11, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Up to you and Suravee, but can't we cleanup this later?
This series was updated many times to address a lot of (sometimes
contradictory) complaints.
Sure. But I'm confident that we can
Just in case let me repeat, I can be easily wrong because I forgot
how this series actually look and I don't have the patches now ;)
On 11/09, Frederic Weisbecker wrote:
>
> On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
> > On 11/08, Frederic Weisbecker wrote:
> > >
> > >
> > >
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
> On 11/08, Frederic Weisbecker wrote:
> >
> > On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com
> > wrote:
> > >
> > > diff --git a/arch/x86/include/asm/cpufeature.h
> > > b/arch/x86/include/asm/cpufeature.h
>
On 11/08, Frederic Weisbecker wrote:
>
> On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> >
> > diff --git a/arch/x86/include/asm/cpufeature.h
> > b/arch/x86/include/asm/cpufeature.h
> > index d3f5c63..26609bb 100644
> > --- a/arch/x86/include/asm/cpufeature.h
> >
On 11/08, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index d3f5c63..26609bb 100644
--- a/arch/x86/include/asm/cpufeature.h
+++
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
On 11/08, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com
wrote:
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index
Just in case let me repeat, I can be easily wrong because I forgot
how this series actually look and I don't have the patches now ;)
On 11/09, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
On 11/08, Frederic Weisbecker wrote:
Does this
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Jacob Shin
>
> 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
On 11/02/2013 01:34 PM, Borislav Petkov wrote:
On Thu, Oct 31, 2013 at 12:23:30PM +0100, Frederic Weisbecker wrote:
Ok we can keep that naming then, at least on the feature symbol. But
add a comment on it.
Great, in the latest F16h BKDG the CPUID bit is called
"DataBreakpointExtension". So
On Sat, Nov 09, 2013 at 06:22:56AM +0900, Suravee Suthikulpanit wrote:
> Sorry for late reply. And yes, the BDKG called it "Breakpoint
> Extension". Keeping the name consistent with the documentation might
> be best for now to avoid confusion.
>
> So, would you like me to send in a new patch to
On Sat, Nov 09, 2013 at 06:22:56AM +0900, Suravee Suthikulpanit wrote:
Sorry for late reply. And yes, the BDKG called it Breakpoint
Extension. Keeping the name consistent with the documentation might
be best for now to avoid confusion.
So, would you like me to send in a new patch to add this
On 11/02/2013 01:34 PM, Borislav Petkov wrote:
On Thu, Oct 31, 2013 at 12:23:30PM +0100, Frederic Weisbecker wrote:
Ok we can keep that naming then, at least on the feature symbol. But
add a comment on it.
Great, in the latest F16h BKDG the CPUID bit is called
DataBreakpointExtension. So BPEXT
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
From: Jacob Shin jacob.w.s...@gmail.com
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
On Thu, Oct 31, 2013 at 12:23:30PM +0100, Frederic Weisbecker wrote:
> Ok we can keep that naming then, at least on the feature symbol. But
> add a comment on it.
Great, in the latest F16h BKDG the CPUID bit is called
"DataBreakpointExtension". So BPEXT could mean anything :)
So the comment is
On Thu, Oct 31, 2013 at 12:23:30PM +0100, Frederic Weisbecker wrote:
Ok we can keep that naming then, at least on the feature symbol. But
add a comment on it.
Great, in the latest F16h BKDG the CPUID bit is called
DataBreakpointExtension. So BPEXT could mean anything :)
So the comment is with
On 10/31, Frederic Weisbecker wrote:
>
> On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> > --- a/arch/x86/include/asm/hw_breakpoint.h
> > +++ b/arch/x86/include/asm/hw_breakpoint.h
> > @@ -12,6 +12,7 @@
> > */
> > struct arch_hw_breakpoint {
> > unsigned
On Thu, Oct 31, 2013 at 11:48:36AM +0100, Borislav Petkov wrote:
> fix tglx's address.
>
> On Thu, Oct 31, 2013 at 10:58:31AM +0100, Frederic Weisbecker wrote:
> > Is this perhaps a bit too generic? Extension can mean about everything
> > and who knows what other feature Intel and Amd will add to
fix tglx's address.
On Thu, Oct 31, 2013 at 10:58:31AM +0100, Frederic Weisbecker wrote:
> Is this perhaps a bit too generic? Extension can mean about everything
> and who knows what other feature Intel and Amd will add to breakpoints
> in the future.
Yeah, but that's the name of the feature.
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Jacob Shin
>
> 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
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
From: Jacob Shin jacob.w.s...@gmail.com
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
fix tglx's address.
On Thu, Oct 31, 2013 at 10:58:31AM +0100, Frederic Weisbecker wrote:
Is this perhaps a bit too generic? Extension can mean about everything
and who knows what other feature Intel and Amd will add to breakpoints
in the future.
Yeah, but that's the name of the feature. When
On Thu, Oct 31, 2013 at 11:48:36AM +0100, Borislav Petkov wrote:
fix tglx's address.
On Thu, Oct 31, 2013 at 10:58:31AM +0100, Frederic Weisbecker wrote:
Is this perhaps a bit too generic? Extension can mean about everything
and who knows what other feature Intel and Amd will add to
On 10/31, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com wrote:
--- a/arch/x86/include/asm/hw_breakpoint.h
+++ b/arch/x86/include/asm/hw_breakpoint.h
@@ -12,6 +12,7 @@
*/
struct arch_hw_breakpoint {
unsigned long address;
From: Jacob Shin
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.
Valuable
From: Jacob Shin jacob.w.s...@gmail.com
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
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.
Valuable advice and pseudo code
On Sat, Apr 27, 2013 at 06:10:28PM +0200, Oleg Nesterov wrote:
> On 04/27, Jacob Shin wrote:
> >
> > On Sat, Apr 27, 2013 at 05:05:10PM +0200, Oleg Nesterov wrote:
> > > ...
> > > > + if (info->mask)
> > > > + set_dr_addr_mask(0, i);
> > >
> > > I agree we should clear
On Sat, Apr 27, 2013 at 06:10:28PM +0200, Oleg Nesterov wrote:
On 04/27, Jacob Shin wrote:
On Sat, Apr 27, 2013 at 05:05:10PM +0200, Oleg Nesterov wrote:
...
+ if (info-mask)
+ set_dr_addr_mask(0, i);
I agree we should clear addr_mask anyway.
But I
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.
Valuable advice and pseudo code
On 04/27, Jacob Shin wrote:
>
> On Sat, Apr 27, 2013 at 05:05:10PM +0200, Oleg Nesterov wrote:
> > ...
> > > + 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
>
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
On 04/27, Oleg Nesterov wrote:
>
> Suppose that the kernel was compiled without CONFIG_CPU_SUP_AMD.
> Then perf_event_open(attr => { .bp_len == 16 }) will succeed,
sorry, I meant "can succeed" if CPU has X86_FEATURE_BPEXT.
Oleg.
--
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
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.
On 04/27, Oleg Nesterov wrote:
Suppose that the kernel was compiled without CONFIG_CPU_SUP_AMD.
Then perf_event_open(attr = { .bp_len == 16 }) will succeed,
sorry, I meant can succeed if CPU has X86_FEATURE_BPEXT.
Oleg.
--
To
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
On 04/27, Jacob Shin wrote:
On Sat, Apr 27, 2013 at 05:05:10PM +0200, Oleg Nesterov wrote:
...
+ 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
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.
Valuable advice and pseudo code
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.
Valuable advice and pseudo code
58 matches
Mail list logo
