RE: [Fault-injection-developer] LKML threads about kprobes

[Wang, S. <sta...@in...>]

There are only four debug register :)
We need more watch point in some complex test case.

> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: 2002=E5=B9=B411=E6=9C=888=E6=97=A5 11:14
> To: Wang, Stanley; Wang, Frank; Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> What about using the debug registers via the kwatch=20
> functions?  Does that solve our MMIO needs?
>=20
> 	-rusty
>=20
> -----Original Message-----
> From: Wang, Stanley=20
> Sent: Thursday, November 07, 2002 7:08 PM
> To: Wang, Frank; Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Kprobes can only capture a specific instruction (by specified=20
> instruction's address).
> It cannot capture all accesses to a specific MMIO address :)
> -----Original Message-----
> From: Wang, Frank [mailto:fra...@in...]
> Sent: 2002?11?8? 10:58
> To: Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> "With kprobes you can register to have a handler called=20
> before a specific address is executed", is this correct?
> The idea of capturing pagefault exception is to capture an=20
> MMIO address access. If the above sentence is correct, why we=20
> continue to capture pagefault exception?
> Or kprobes enables you capture a specific address access but=20
> it must be with interrupt-enabled? Why is it? Can we change=20
> the kprobe to enable this in interrupt-disabled condition?
> -----Original Message-----
> From: Zhuang, Louis [mailto:lou...@in...]
> Sent: 2002?11?8? 9:31
> To: Lynch, Rusty; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Yes, It is not enough. FITH needs capture pagefault exception=20
> in interrept-disabled condition, just as kprobes for=20
> do_int3/do_debug.=20
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Friday, November 08, 2002 9:02 AM
> To: Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Ok, now I'm confused.  With kprobes you can register to have=20
> a handler called before a specific address is executed.  Why=20
> is that not enough?
>=20
>     -rusty
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Thursday, November 07, 2002 4:48 PM
> To: Lynch, Rusty; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Hi, Rusty
>     We did work based on kprobes. After we investigated=20
> kprobes, we found kprobes had removed GKHI support. So we=20
> need to find another way to get additional control in=20
> exception handling... This is a problem we need to solve in 2.5.x
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Friday, November 08, 2002 1:30 AM
> To: Zhuang, Louis; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> It looks to me like kprobes will make it in the kernel.  Why=20
> don't we work under that assumption for now.
>=20
>     -rusty
> -----Original Message-----
> From: Zhuang, Louis [mailto:lou...@in...]
> Sent: Thursday, November 07, 2002 12:27 AM
> To: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Humm... kprobes in 2.5.x removed GKHI(General Kernel Hook=20
> Interface) mechanism, which FITH needed. But all kprobes=20
> patch in 2.5.x is useful for FITH, such as do_int3/do_debug=20
> interrupt gate. We need a mederate patch to hook these=20
> exception for FITH. But I wonder if this can be accepted by=20
> LKML. Any comments
>     -Louis
>=20