> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > On 18 June 2015 at 08:12, Pavel Dovgaluk <pavel.dovga...@ispras.ru> wrote: > >> From: Aurelien Jarno [mailto:aurel...@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
