From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUgfE-0002qC-Lw for qemu-devel@nongnu.org; Wed, 26 Aug 2015 15:47:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUgfB-0005p2-AH for qemu-devel@nongnu.org; Wed, 26 Aug 2015 15:47:16 -0400 Received: from mail-qg0-x22c.google.com ([2607:f8b0:400d:c04::22c]:33456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUgfB-0005ot-5r for qemu-devel@nongnu.org; Wed, 26 Aug 2015 15:47:13 -0400 Received: by qgeh99 with SMTP id h99so422311qge.0 for ; Wed, 26 Aug 2015 12:47:12 -0700 (PDT) Sender: Richard Henderson References: <34e409ed-ee30-46b7-932b-46eef9a350e9@email.android.com> From: Richard Henderson Message-ID: <55DE17BC.1050306@twiddle.net> Date: Wed, 26 Aug 2015 12:47:08 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Dennis Luehring , qemu-devel , Aurelien Jarno On 08/26/2015 09:17 AM, Artyom Tarasenko wrote: > After some debugging I think it's caused by memory faults. On every > MMU miss / access fault > TB is re-translated multiple times till the faulting instruction is found. That shouldn't happen. Are you certain it's not multiple MMU misses/faults? > AFAICT we produce data/access faults only on load/store instructions, i.e. > if GET_FIELD(insn, 0, 1) == 3. Can this knowledge be used to reduce > the number of re-translations? No. From the fault, we have a host address where the fault occured. We then retranslate the TB looking for what guest address corresponds to the code generated at the host address. This is a one-pass process, not the multiple passes you seem to be imagining. It also means we can't skip non-memory insns during retranslation, as the host addresses would no longer line up. That said, sun4u is a software managed tlb, which requires *lots* more extra faults than a hardware managed tlb. In the later case, we can perform the page table lookup and then continue the memory instruction without faulting. I think that implementing sun4v, with (most of) the hypervisor actually within qemu, is the only way to get good performance for Sparc. Anyway, this sort of setup is exactly what I did for Alpha. The PALcode (hypervisor-ish) layer used for qemu looks nothing like the PALcode layer used for real hardware. r~