From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5284 invoked by alias); 3 Aug 2005 14:46:33 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 5264 invoked by uid 22791); 3 Aug 2005 14:46:24 -0000 Date: Wed, 03 Aug 2005 14:46:00 -0000 From: Andi Kleen To: Satoshi Oshima Cc: Richard J Moore , systemtap@sources.redhat.com, Andi Kleen , Mathieu Desnoyers , Masami Hiramatsu , Karim Yaghmour , Masami Hiramatsu , michel.dagenais@polymtl.ca, Roland McGrath , sugita@sdl.hitachi.co.jp Subject: Re: Hitachi djprobe mechanism Message-ID: <20050803144606.GB10895@wotan.suse.de> References: <42EE7E97.7080501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EE7E97.7080501@redhat.com> X-SW-Source: 2005-q3/txt/msg00258.txt.bz2 > 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