From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHhYw-0002n3-T4 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:39:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHhYs-0002kT-6p for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:39:54 -0500 Received: from [199.232.76.173] (port=45687 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHhYr-0002kI-UM for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:39:49 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:49544) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHhYs-0006mT-AN for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:39:50 -0500 Received: by yxe26 with SMTP id 26so4346340yxe.4 for ; Mon, 07 Dec 2009 09:39:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <200912071506.02310.paul@codesourcery.com> References: <200912071506.02310.paul@codesourcery.com> From: Artyom Tarasenko Date: Mon, 7 Dec 2009 18:39:28 +0100 Message-ID: Subject: Re: [Qemu-devel] irq latency and tcg Content-Type: text/plain; charset=ISO-8859-1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Blue Swirl , qemu-devel@nongnu.org 2009/12/7 Paul Brook : > On Monday 07 December 2009, Artyom Tarasenko wrote: >> Can it be that qemu (-system-sparc in my case, but I guess it's more >> or less similar on all platforms) reacts to irqs slower than a real >> hardware due to tcg optimizations? > > Interrupts generally only trigger at branch instructions, or similar. > > Using -icount should give you precise interrupt delivery. That's what I thought, but as I reported a few days ago, I couldn't find a good value for icount when using OBP. I tried a few values but keep getting "qemu: fatal: Raised interrupt while not in I/O function". Also I got a report from other person where qemu crashed with another message: "qemu: fatal: Trap 0x29 while interrupts disabled". What could be a good value for -icount? Is it host-cpu specific? Isn't it a bug that qemu crashes [at least] on some icount values?