Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756706Ab0A2Ezy (ORCPT ); Thu, 28 Jan 2010 23:55:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756683Ab0A2Ezx (ORCPT ); Thu, 28 Jan 2010 23:55:53 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:53978 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756674Ab0A2Ezw (ORCPT ); Thu, 28 Jan 2010 23:55:52 -0500 Date: Fri, 29 Jan 2010 10:25:46 +0530 From: Ananth N Mavinakayanahalli To: Ingo Molnar Cc: Jim Keniston , Stephen Rothwell , Kyle Moffett , Arnaldo Carvalho de Melo , Peter Zijlstra , Fr??d??ric Weisbecker , Oleg Nesterov , Steven Rostedt , LKML , Tom Tromey , "Frank Ch. Eigler" , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Linus Torvalds , Thomas Gleixner Subject: Re: linux-next: add utrace tree Message-ID: <20100129045546.GA16920@in.ibm.com> Reply-To: ananth@in.ibm.com References: <1264575134.4283.1983.camel@laptop> <20100127085442.GA28422@elte.hu> <1264643539.5068.62.camel@localhost.localdomain> <20100128085502.GA7713@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100128085502.GA7713@elte.hu> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2191 Lines: 56 On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote: ... > Lets compare the two cases via a drawing. Your current uprobes submission > does: > > [kernel] do probe thing single-step trap > ^ | ^ | > | v | v > [user] INT3 XOL-ins next ins-stream > > ( add the need for serialization to make sure the whole single-step thing > does not get out of sync with reality. ) > > And emulator approach would do: > > [kernel] emul-demux-fastpath, do probe thing > ^ | > | v > [user] INT3 next ins-stream > > far simpler conceptually, and faster as well, because it's one kernel entry. Ingo, Yes, conceptually, emulation is simpler. In fact, it may even be the right thing to do from a housekeeping POV if gdb were enabled to use breakpoint assistance in the kernel. However... emulation is not easy. Just quoting Peter Anvin: > On the more general rule of interpretation: I'm really concerned about > having a bunch of partially-capable x86 interpreters all over the > kernel. x86 is *hard* to emulate, and it will only get harder as the > architecture evolves. > > -hpa Yes, I know you suggested we start with a small subset. We already have an implementation of instruction emulation in kernel for x86 and powerpc, but its too KVM centric. If there is a generic emulation layer, we would use it. There are conflicting opinions for either case; complicated as it is, the XOL scheme works and, to a large extent, it is easily extendable to other architectures compared to the emulation approach. Uprobes can be made to use emulation when possible/available, but I don't think this should be gating decision for the initial implementation of the feature. Ananth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/