From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ubn-0007Az-H8 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:51:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Ubj-0007Wt-E1 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:51:35 -0400 Received: from mail-yh0-f41.google.com ([209.85.213.41]:33944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ubj-0007Wl-9x for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:51:31 -0400 Received: by yhnv31 with SMTP id v31so24944663yhn.1 for ; Thu, 18 Jun 2015 00:51:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <55826f70.2215370a.4634.ffff91b2SMTPIN_ADDED_BROKEN@mx.google.com> References: <20150617124158.3316.54954.stgit@PASHA-ISP> <20150617141901.GE19635@aurel32.net> <55826f70.2215370a.4634.ffff91b2SMTPIN_ADDED_BROKEN@mx.google.com> From: Peter Maydell Date: Thu, 18 Jun 2015 08:51:10 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2 0/3] Fix exceptions handling for MIPS and i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgaluk Cc: Paolo Bonzini , Richard Henderson , Leon Alrae , QEMU Developers , Aurelien Jarno On 18 June 2015 at 08:12, Pavel Dovgaluk wrote: >> From: Aurelien Jarno [mailto:aurelien@aurel32.net] >> Looking at how icount work, I see it's basically a variable in the CPU >> state (icount_decr.u16.low), which is already accessed from the TB. >> Couldn't we adjust it using additional code before generating an >> exception, when in icount mode. >> >> For example for MIPS, we can add some code before generate_exception >> which use the value from s->gen_opc_icount[j] to adjust >> the variable icount_decr.u16.low. > > It is possible, but it will incur additional overhead, because we will > have to update icount every time the exception might be generated. > We'll have to update icount value before and after every helper call, > that can cause an exception: > > icount -= n > ... > instr_k > icount += n - k > helper > icount -= n - k > ... > > And this overhead will slowdown the code even if no exception occur. Right, this is a tradeoff: in some cases it's faster to assume no exception and handle state resync by doing a retranslate. In some cases it's faster to assume there will be an exception and do a manual sync. Guest load/store is obviously in the first category. Guest doing an instruction which always takes an exception (like syscall insns) is in the second category. For other cases there's a choice. We need to support both approaches; obviously you can argue for any particular case whether it should be approach 1 or approach 2. thanks -- PMM