This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Andi Kleen <ak at suse dot de>
- To: Satoshi Oshima <soshima at redhat dot com>
- Cc: Richard J Moore <richardj_moore at uk dot ibm dot com>,systemtap at sources dot redhat dot com, Andi Kleen <ak at suse dot de>,Mathieu Desnoyers <compudj at krystal dot dyndns dot org>,Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>,Karim Yaghmour <karim at opersys dot com>,Masami Hiramatsu <masami dot hiramatsu at gmail dot com>,michel dot dagenais at polymtl dot ca, Roland McGrath <roland at redhat dot com>,sugita at sdl dot hitachi dot co dot jp
- Date: Wed, 3 Aug 2005 16:46:06 +0200
- Subject: Re: Hitachi djprobe mechanism
- References: <OF331D042E.CCADD212-ON41257050.002DC63A-41257050.002F8168@uk.ibm.com> <42EE7E97.7080501@redhat.com>
> step 2: safety check;
> make sure that all CPUs don't run on the code that will
> be replaced with jmp instruction (also check whether stack
> include EIP of the code which is subject to replace)
I don't think there is a race free way to do this without an IPI to
all CPUs. And if you do that you can as well do it simpler.
> step 4: i-cache flush or serializing:
> invoke i-cache flush instruction such as CLFLASH or serialize
> instruction such as CPUID on all CPUs (new step)
I'm not sure these flushes are needed. With IPIs certainly not.
-Andi