From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5WeJ-0004ez-HH for qemu-devel@nongnu.org; Thu, 18 Jun 2015 06:02:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5WeG-0003hB-8e for qemu-devel@nongnu.org; Thu, 18 Jun 2015 06:02:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5WeG-0003h2-1Z for qemu-devel@nongnu.org; Thu, 18 Jun 2015 06:02:16 -0400 Message-ID: <55829723.60009@redhat.com> Date: Thu, 18 Jun 2015 12:02:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20150617124158.3316.54954.stgit@PASHA-ISP> <20150617141901.GE19635@aurel32.net> <001101d0a996$19a72f80$4cf58e80$@Dovgaluk@ispras.ru> <20150618081640.GK931@aurel32.net> <20150618090813.GF19635@aurel32.net> <55828F5C.70706@redhat.com> <20150618094254.GE3379@aurel32.net> In-Reply-To: <20150618094254.GE3379@aurel32.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 , rth7680@gmail.com, leon.alrae@imgtec.com, qemu-devel@nongnu.org On 18/06/2015 11:42, Aurelien Jarno wrote: >> > QEMU could just always compute and store the restore_state informati= on. >> > TCG needs to help filling it in (a new TCG opcode?), but it should = be easy. > Yes, that was another approach I have in mind (I called it exception > table in my other mail), Okay, understood. My idea was more like always generating the gen_op_* arrays. > but it requires a tiny more work than just > saving the CPU state all the time. The problem is that the state > information we want to save are varying for target to target. Going > through a TCG opcode means we can use the liveness analysis pass to sav= e > the minimum amount of data. I mentioned a TCG opcode because the target PC is not available inside the translator. So the translator could pepper the TCG instruction stream with things like checkpoint $target_pc, $target_cc_op, $0 TCG can then use them to fill in an array stored inside the TranslationBlock, together with the host PC. Since the gen_opc_pc, gen_opc_instr_start, gen_opc_icount arrays are inside tcg_ctx, it may be a good idea to store the checkpoint information compressed in a byte array (e.g. as a series of ULEB128 values---the host and target PCs can even be stored as deltas from the last value). As a first step, gen_intermediate_code_pc and tcg_gen_code_search_pc can then be merged into a single target-independent function that uncompresses the byte array up to the required host PC into tcg_ctx. Later you can optimize them to remove the tcg_ctx arrays altogether. So the patches could be something like this: 1) SPARC: put the jump target information directly in gen_opc_* without using gen_opc_jump_pc (not trivial) 2) a few targets: instead of gen_opc_* arrays, use a new generic member of tcg_ctx (similar to how csbase is used generically), e.g. tcg_ctx.gen_opc_target1[] and tcg_ctx.gen_opc_target2[]. 3) all targets: always fill in tcg_ctx.gen_*, even if search_pc is false 4) TCG: add support for a checkpoint operation, make it fill in tcg_ctx.gen_* 5) all targets: change explicit filling of tcg_ctx.gen_* to use the checkpoint operation 6) TCG/translate-all: convert gen_intermediate_code_pc as outlined above > That said I would like to push further the idea of always saving the CP= U > state a bit more to see if we can keep the same performances. There are > still improvements to do, by removing more code on the core side (like > finding the call to tb_finc_pc which is now useless), or on the target > side by checking/improving helper flags. We might save the CPU state to= o > often if a helper doesn't declare it doesn't touch globals. True, on the other hand there are a lot of helpers to audit... Paolo