From: Frederic Weisbecker <fweisbec@gmail.com>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: Will Deacon <will.deacon@arm.com>,
David Ahern <dsahern@gmail.com>, Gleb Natapov <gleb@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"avi@redhat.com" <avi@redhat.com>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
"linux-kernel@redhat.com" <linux-kernel@redhat.com>,
"mingo@elte.hu" <mingo@elte.hu>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"acme@ghostprotocols.net" <acme@ghostprotocols.net>
Subject: Re: [PATCH 6/9] perf: expose perf capability to other modules.
Date: Tue, 15 Nov 2011 19:34:35 +0100 [thread overview]
Message-ID: <20111115183428.GC3234@somewhere> (raw)
In-Reply-To: <4EBBBFA7.7010901@windriver.com>
On Thu, Nov 10, 2011 at 06:12:23AM -0600, Jason Wessel wrote:
> On 11/10/2011 02:58 AM, Frederic Weisbecker wrote:
> > On Mon, Nov 07, 2011 at 02:45:17PM +0000, Will Deacon wrote:
> >> Hi Frederic,
> >>
> >> On Wed, Nov 02, 2011 at 07:42:04AM +0000, Frederic Weisbecker wrote:
> >>> On Tue, Nov 01, 2011 at 10:20:04AM -0600, David Ahern wrote:
> >>>> Right. Originally it could be enabled/disabled. Right now it cannot be,
> >>>> but I believe Frederic is working on making it configurable again.
> >>>>
> >>>> David
> >>> Yep. Will Deacon is working on making the breakpoints able to process
> >>> pure arch informations (ie: without beeing forced to use the perf attr
> >>> as a midlayer to define them).
> >>>
> >>> Once we have that I can seperate the breakpoints implementation from perf
> >>> and make it opt-able.
> >> How do you foresee kdb fitting into this? I see that currently [on x86] we
> >> cook up perf_event structures with a specific overflow handler set. If we
> >> want to move this over to using a completely arch-defined structure, then
> >> we're going to end up with an overflow handler field in both perf_event
> >> *and* the arch-specific structure, which doesn't feel right to me.
> >>
> >> Of course, if the goal is only to separate ptrace (i.e. user debugging) from
> >> the perf dependency then we don't need the overflow handler because we'll
> >> always just send SIGTRAP to the current task.
> >>
> >> Any ideas?
> > I don't know if we want to convert x86/kgdb to use pure arch breakpoints.
> > If kgdb one day wants to extend this use to generic code, it may be a good
> > idea to keep the things as is. I don't know, I'm adding Jason in Cc.
>
> I think the important part is to share the allocation code (meaning who owns which break point slots). This is why kgdb/kdb allocates the perf structures. The kgdb code will also directly write data to the slots once it has reserved them it would be good to share this code, but it was not shared because it was not usable early enough in the boot cycle on x86.
>
> Certainly there are others who could consume the same infrastructure such as kprobes.
>
> Jason.
Yeah sure, in any case we want to keep the slot allocation/reservation handled in
kernel/event/hw_breakpoint.c
next prev parent reply other threads:[~2011-11-15 18:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-30 16:53 [PATCH 0/9] KVM in-guest performance monitoring Gleb Natapov
2011-10-30 16:53 ` [PATCH 1/9] KVM: Expose kvm_lapic_local_deliver() Gleb Natapov
2011-10-30 16:53 ` [PATCH 2/9] KVM: Expose a version 2 architectural PMU to a guests Gleb Natapov
2011-11-01 10:47 ` Avi Kivity
2011-11-01 12:30 ` Gleb Natapov
2011-11-01 13:57 ` Gleb Natapov
2011-11-02 9:54 ` Avi Kivity
2011-11-02 9:56 ` Gleb Natapov
2011-11-02 10:01 ` Avi Kivity
2011-11-02 11:09 ` Gleb Natapov
2011-11-02 12:03 ` Gleb Natapov
2011-11-03 8:31 ` Gleb Natapov
2011-12-15 12:04 ` [PATCH] KVM: x86: Fix build breakage due to anonymous field initialization Jan Kiszka
2011-12-15 12:08 ` Peter Zijlstra
2011-12-15 12:16 ` Jan Kiszka
2011-12-26 12:38 ` Avi Kivity
2011-10-30 16:53 ` [PATCH 3/9] KVM: Add generic RDPMC support Gleb Natapov
2011-10-30 16:53 ` [PATCH 4/9] KVM: SVM: Intercept RDPMC Gleb Natapov
2011-10-30 16:53 ` [PATCH 5/9] KVM: VMX: " Gleb Natapov
2011-10-30 16:53 ` [PATCH 6/9] perf: expose perf capability to other modules Gleb Natapov
2011-11-01 10:49 ` Avi Kivity
2011-11-01 15:49 ` David Ahern
2011-11-01 16:13 ` Gleb Natapov
2011-11-01 16:20 ` David Ahern
2011-11-01 16:41 ` Gleb Natapov
2011-11-02 7:42 ` Frederic Weisbecker
2011-11-07 14:45 ` Will Deacon
2011-11-10 8:58 ` Frederic Weisbecker
2011-11-10 12:12 ` Jason Wessel
2011-11-15 18:34 ` Frederic Weisbecker [this message]
2011-10-30 16:53 ` [PATCH 7/9] KVM: Expose the architectural performance monitoring CPUID leaf Gleb Natapov
2011-11-01 10:51 ` Avi Kivity
2011-11-01 11:25 ` Gleb Natapov
2011-11-01 15:49 ` David Ahern
2011-11-01 16:18 ` Gleb Natapov
2011-11-01 16:24 ` David Ahern
2011-11-01 16:40 ` Gleb Natapov
2011-11-01 17:43 ` David Ahern
2011-11-02 11:18 ` Gleb Natapov
2011-10-30 16:53 ` [PATCH 8/9] KVM: x86 emulator: fix RDPMC privilege check Gleb Natapov
2011-10-30 16:53 ` [PATCH 9/9] KVM: x86 emulator: implement RDPMC (0F 33) Gleb Natapov
2011-10-30 16:57 ` [PATCH 0/9] KVM in-guest performance monitoring Gleb Natapov
-- strict thread matches above, loose matches on Subject: below --
2011-11-03 12:31 Gleb Natapov
2011-11-03 12:31 ` [PATCH 6/9] perf: expose perf capability to other modules Gleb Natapov
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=20111115183428.GC3234@somewhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=avi@redhat.com \
--cc=dsahern@gmail.com \
--cc=gleb@redhat.com \
--cc=jason.wessel@windriver.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@redhat.com \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=will.deacon@arm.com \
/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