From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFA5I-0006eA-Nb for qemu-devel@nongnu.org; Mon, 30 Nov 2009 12:30:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFA5F-0006af-2F for qemu-devel@nongnu.org; Mon, 30 Nov 2009 12:30:48 -0500 Received: from [199.232.76.173] (port=45293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFA5E-0006aU-Nl for qemu-devel@nongnu.org; Mon, 30 Nov 2009 12:30:44 -0500 Received: from thoth.sbs.de ([192.35.17.2]:20550) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFA5E-000500-Cg for qemu-devel@nongnu.org; Mon, 30 Nov 2009 12:30:44 -0500 Message-ID: <4B140141.1040708@siemens.com> Date: Mon, 30 Nov 2009 18:30:41 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/7] KVM SMP support, early version References: <1259256300-23937-1-git-send-email-glommer@redhat.com> <4B12B042.9020409@web.de> <5d6222a80911300342x4d29653as6c23acac598dec64@mail.gmail.com> <5d6222a80911300755o4fed5447w9ddae1abaccf7100@mail.gmail.com> <4B13F570.4030605@redhat.com> <5d6222a80911300847w2faa9d39nb2fc6ee3ccb9ccfd@mail.gmail.com> In-Reply-To: <5d6222a80911300847w2faa9d39nb2fc6ee3ccb9ccfd@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: qemu-devel@nongnu.org, Glauber Costa , Avi Kivity , aliguori@us.ibm.com Glauber Costa wrote: > On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity wrote: >> On 11/30/2009 05:55 PM, Glauber Costa wrote: >>> reset code is responsible for most remote calls in qemu. One of the >>> only ones we still >>> have left is the gdb stuff. Do you have any suggestion to do that >>> without the current >>> on_vcpu mechanism? >>> >> No. But what's wrong with on_vcpu? > > intrinsically racy. signal passing slow down things, etc. > > That said, as I've stated many times: I don't believe there's anything > fundamentally wrong with on_vcpu. But we might get benefits from a re-design > of things to avoid it whenever possible. (just like the vcpu_reset() > I've just posted) > If you don't want immediate execution of update_guest_debug, save the state that shall be transferred, set some flag, and run the transfer before guest entry inside the vcpu threads (after putting the registers as older kernels may otherwise overwrite the flags register). Should work, may even avoid redundant calls during a gdb session. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux