qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to spe


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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]