From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: [PATCH] paravirt.h Date: Wed, 23 Aug 2006 02:14:36 -0700 Message-ID: <44EC1C7C.9020304@vmware.com> References: <1155202505.18420.5.camel@localhost.localdomain> <200608231050.13272.ak@suse.de> <44EC194E.6080606@vmware.com> <200608231106.26696.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200608231106.26696.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org To: Andi Kleen Cc: Arjan van de Ven , virtualization@lists.osdl.org, Jeremy Fitzhardinge , Andrew Morton , Chris Wright , Linux Kernel Mailing List List-Id: virtualization@lists.linuxfoundation.org Andi Kleen wrote: > On Wednesday 23 August 2006 11:01, Zachary Amsden wrote: > >> Andi Kleen wrote: >> >>>> Yes, after discussion with Rusty, it appears that beefing up >>>> stop_machine_run is the right way to go. And it has benefits for >>>> non-paravirt code as well, such as allowing plug-in kprobes or oprofile >>>> extension modules to be loaded without having to deal with a debug >>>> exception or NMI during module load/unload. >>>> >>>> >>> I'm still unclear where you think those debug exceptions will come from >>> >> kprobes set in the stop_machine code - which is probably a really bad >> idea, but nothing today actively stops kprobes from doing that. >> > > kprobes don't cause any debug exceptions. You mean int3? > > Anyways this can be fixed by marking the stop machine code __kprobes > > -Andi > I need to look at the kprobes code in more depth to answer completely. But in general, there could be a problem if DRs are set to fire on any EIP or memory address touched during the critical stop_machine region, or int3 breakpoints are set in that code or any code it calls. Zach