Messages in this thread | | | Date | Fri, 29 Jan 2010 10:25:46 +0530 | From | Ananth N Mavinakayanahalli <> | Subject | Re: 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
| |