From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ugo-0003IQ-L9 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:56:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Ugk-00042q-Cd for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:56:46 -0400 Received: from mail.ispras.ru ([83.149.199.45]:58143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ugk-00041w-5T for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:56:42 -0400 From: "Pavel Dovgaluk" References: <20150617124158.3316.54954.stgit@PASHA-ISP> <20150617141901.GE19635@aurel32.net> <55826f70.2215370a.4634.ffff91b2SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 18 Jun 2015 10:56:42 +0300 Message-ID: <001201d0a99c$50f0b910$f2d22b30$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru 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: 'Peter Maydell' Cc: 'Paolo Bonzini' , 'Richard Henderson' , 'Leon Alrae' , 'QEMU Developers' , 'Aurelien Jarno' > From: Peter Maydell [mailto:peter.maydell@linaro.org] > 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. Syscall and non-implemented instructions are in third category - they always take an exception. In this case the translation should be stopped without any additional actions. By the way, I implemented this 'third category' approach for mips and measured the performance. It does not show any performance degradation when compared to original unfixed version. All other exception-generating helpers and instructions use approach 1. Pavel Dovgalyuk