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: Artyom Tarasenko
Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation?
Date: Thu, 27 Aug 2015 17:58:07 +0200

On Wed, Aug 26, 2015 at 9:47 PM, Richard Henderson <address@hidden> wrote:
> 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?

You are right. These are multiple 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.

Right, thanks for clarifying this. I was confused by the multiple
"Search PC..." messages.
But I see now that one message corresponds to one translated instruction,
not to one translation block. The log message should probably be moved
one level up, and btw it's not sparc-specific, this part seems to be a
copy-pasta in multiple targets.

> 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.

I thought about it. The guest can profit from the knowledge it is executed
virtualized in multiple ways.

The problem with this approach is that Linux/sparc64 is currently not
the primary target OS for me.
And the legacy OSes do not support sun4v. Even a Solaris 8 has a quite
limited support for it.

Artyom

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu



reply via email to

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