|
From: | Richard Henderson |
Subject: | Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation? |
Date: | Wed, 26 Aug 2015 12:47:08 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
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~
[Prev in Thread] | Current Thread | [Next in Thread] |