Re: [PATCH -tip v8 0/7] tracing: kprobe-based event tracer and x86 instruction decoder

Small question to start with: What's your (or Hitachi s/Red Hat's) use case for this? It's obviously really cool technology, but I fear without some good user space side to make it easy to use it will most likely bit-rot which would be sad. -- To unsubscribe from this list: send the line

Re: [PATCH -tip v8 5/7] x86: add pt_regs register and stack access APIs

You might want to run this past linux-arch to make sure this is suitable for other architectures. --- a/arch/x86/include/asm/ptrace.h +++ b/arch/x86/include/asm/ptrace.h @@ -7,6 +7,7 @@ #ifdef __KERNEL__ #include asm/segment.h +#include asm/page_types.h #endif I really wonder if we

Re: [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer

On Thu, May 28, 2009 at 08:03:53PM -0400, Masami Hiramatsu wrote: Add kprobes-based event tracer on ftrace. Wouldn't it make more sense to call this the dynamic event tracer? The use of kprobes is more an implementation detail than something the user cares about. -- To unsubscribe from this

Re: Status of pci passthrough work?

Hi Pablo, On (Fri) May 29 2009 [11:41:58], Passera, Pablo R wrote: Hi Amit, Please correct me if I am wrong, but the fact that the PVDMA module is located in the guest imposes a security problem. So, if someone in the guest has root access, he could modify the PVDMA module and

[RFC][PATCH] qemu-kvm: vl.c remove unused functions gethugepagesize() and alloc_mem_area()

No user is available for functions gethugepagesize() and alloc_mem_area() Fixes : CCx86_64-softmmu/vl.o /home/jaswinder/jaswinder-git/qemu-kvm/vl.c:4884: warning: ‘alloc_mem_area’ defined but not used Signed-off-by: Jaswinder Singh Rajput jaswinderraj...@gmail.com --- vl.c | 84

[PATCH] x86info: mtrr.c return if MTRR registers are not accessible

In some virtualization systems like KVM where MTRR registers are not accessible output looks like : MTRR registers: MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206):

Re: [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer

Steven Rostedt wrote: On Thu, 28 May 2009, Masami Hiramatsu wrote: +#undef SHOW_FIELD +#define SHOW_FIELD(type, item, name) \ +do {\ +ret = trace_seq_printf(s, \tfield:

Re: [PATCH] x86info: mtrr.c return if MTRR registers are not accessible

On Sat, May 30, 2009 at 06:38:38PM +0530, Jaswinder Singh Rajput wrote: In some virtualization systems like KVM where MTRR registers are not accessible output looks like : MTRR registers: MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202):

Re: [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer

Christoph Hellwig wrote: On Thu, May 28, 2009 at 08:03:53PM -0400, Masami Hiramatsu wrote: Add kprobes-based event tracer on ftrace. Wouldn't it make more sense to call this the dynamic event tracer? The use of kprobes is more an implementation detail than something the user cares about.

Re: [PATCH -tip v8 5/7] x86: add pt_regs register and stack access APIs

Hi Christoph, Thank you for review. Christoph Hellwig wrote: You might want to run this past linux-arch to make sure this is suitable for other architectures. Frankly, I'm not sure about linux-arch, could you explain it? Anyway, I'm interested in that idea. ---

configure script bug..

Hit this yesterday when configure hung attempting to pull the version from a kernel's .config. diff --git a/configure b/configure index 493c178..1fd133c 100755 --- a/configure +++ b/configure @@ -126,7 +126,7 @@ if [ -n $no_uname ]; then elif [ -e $kerneldir/include/config/kernel.release ];