From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJbPZ-00049V-Pi for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:30:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJbPV-000445-5t for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:30:05 -0500 Received: from [199.232.76.173] (port=56468 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJbPV-00043y-3V for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:30:01 -0500 Received: from mx20.gnu.org ([199.232.41.8]:40097) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NJbPU-0004Yz-RM for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:30:00 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJbPT-0003Ak-6L for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:29:59 -0500 From: Paul Brook Date: Sat, 12 Dec 2009 23:29:48 +0000 References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200912122329.48660.paul@codesourcery.com> Subject: [Qemu-devel] Re: irq latency and tcg List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel , Artyom Tarasenko > According to comment in exec-all.h: > /* Deterministic execution requires that IO only be performed on the last > instruction of a TB so that interrupts take effect immediately. */ > > Sparc generator must then violate this assumption. Is the assumption > valid also when not using icount and should the check be enabled for > all cases, not just icount? Not really. With -icount we're trying to achieve deterministic behavior[1]. When icount is disabled a few extra instructions interrupt latency is the least of your problems. I guess with in-core peripherals you may be able to accurately predict interrupt response. However for the vast majority of cases I wouldn't be surprised if real hardware has a few cycles latency anyway. Paul [1] Even with -icount, qemu is still a long way from being cycle accurate. The goal is to give reproducible and consistent results. Actual realtime characteristics are still likely to be very different from real hardware. Paul