From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH 6/9] perf: expose perf capability to other modules. Date: Thu, 10 Nov 2011 09:58:43 +0100 Message-ID: <20111110085839.GC19247@somewhere.redhat.com> References: <1319993624-20247-1-git-send-email-gleb@redhat.com> <1319993624-20247-7-git-send-email-gleb@redhat.com> <4EB014FF.5000509@gmail.com> <20111101161352.GA16539@redhat.com> <4EB01C34.9060106@gmail.com> <20111102074148.GA8198@somewhere.redhat.com> <20111107144517.GD5454@mudshark.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Ahern , Gleb Natapov , "kvm@vger.kernel.org" , "avi@redhat.com" , "mtosatti@redhat.com" , "linux-kernel@redhat.com" , "mingo@elte.hu" , "a.p.zijlstra@chello.nl" , "acme@ghostprotocols.net" , Jason Wessel To: Will Deacon Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:46270 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146Ab1KJI6s (ORCPT ); Thu, 10 Nov 2011 03:58:48 -0500 Received: by vws1 with SMTP id 1so2147364vws.19 for ; Thu, 10 Nov 2011 00:58:47 -0800 (PST) Content-Disposition: inline In-Reply-To: <20111107144517.GD5454@mudshark.cambridge.arm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. In any case I think we have a problem if we want to default to send a SIGTRAP. Look at this: bp = per_cpu(bp_per_reg[i], cpu); /* * Reset the 'i'th TRAP bit in dr6 to denote completion of * exception handling */ (*dr6_p) &= ~(DR_TRAP0 << i); /* * bp can be NULL due to lazy debug register switching * or due to concurrent perf counter removing. */ if (!bp) { rcu_read_unlock(); break; } perf_bp_event(bp, args->regs); I don't have the details about how lazy the debug register switching can be. And also we want to avoid a locking between the perf event scheduling (removing) and the breakpoint triggering path. A solution is to look at the ptrace breakpoints in the thread struct and see if the one in the index is there. That can reside in its own callback or as a fallback in hw_breakpoint_handler(). I don't feel that strong with choosing either of those solutions.