lkml.org 
[lkml]   [2010]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: add utrace tree
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


\
 
 \ /
  Last update: 2010-01-29 05:59    [W:0.165 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site