From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38998 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py2WY-0002Lj-96 for qemu-devel@nongnu.org; Fri, 11 Mar 2011 08:36:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Py2WW-0005Ua-Sk for qemu-devel@nongnu.org; Fri, 11 Mar 2011 08:36:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Py2WW-0005To-KM for qemu-devel@nongnu.org; Fri, 11 Mar 2011 08:36:56 -0500 Message-ID: <4D7A2571.7000704@redhat.com> Date: Fri, 11 Mar 2011 14:36:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1299759171-26095-1-git-send-email-pbonzini@redhat.com> <20110311125717.GB13236@edde.se.axis.com> In-Reply-To: <20110311125717.GB13236@edde.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 0/3] really fix -icount with iothread List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: jan.kiszka@web.de, qemu-devel@nongnu.org On 03/11/2011 01:57 PM, Edgar E. Iglesias wrote: > Hi Paulo, > > I gave this patchset a run and it runs icount and iothread very > fast in all my testcases. Thanks, that's good news. > But, it suffers from the problem that commit > 225d02cd1a34d5d87e8acefbf8e244a5d12f5f8c > tried to fix. > > If the virtual CPU goes to sleep waiting for a future timer > interrupt to wake it up, qemu deadlocks. > > The timer interrupt never comes because time is driven by > icount, but the vCPU doesn't run any insns. I'm not sure what it should wait for, though. Is vm_clock supposed to be "a count of instructions, or real time if there is need for?" So, it's not clear to me what the correct behavior should be in this case. Does it make sense to wait at all? Thinking more about it, perhaps VCPUs should never go to sleep in icount mode if there is a pending vm_clock timer; rather time should just warp to the next vm_clock event with no sleep ever taking place. (That's my reasoning for manual -icount mode, at least; I think "-icount auto" will just work thanks to the icount_rt_handler). Bonus question: how does -icount mode makes sense at all for SMP? :) Paolo