[Top][All Lists]

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

Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures

From: Blue Swirl
Subject: Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
Date: Sat, 25 May 2013 17:48:56 +0000

On Fri, May 24, 2013 at 7:24 PM, Lior Vernia <address@hidden> wrote:
> Hello,
> I am running x86 applications on an ARM device using QEMU, and found
> it too slow for my needs. This is to be expected, of course, this is
> not a complaint. However, I was wondering whether this could be helped
> by "overriding" the generic binary translation mechanism and focusing
> on lower level binary translation just from x86 to ARM.
> It's clear to me that this isn't a small project, but it might be
> important enough for me to invest myself in. However, before I jump
> into it, I wanted to inquire whether this would be worthwhile at all.
> Does anyone have any estimate as to how big of a gain that could
> achieve? Or whether a more significant improvement could be achieved
> by further tweaking that didn't occur to me?

You could introduce new optionally implemented TCG ops which match x86
instructions and then implement hand crafted (or produced by LLVM or
GCC back end) versions for ARM TCG target. I doubt this would improve
performance much because we didn't lose much performance when we moved
from earlier dyngen code generation model to current TCG.

It may be possible to extend the VM part of KVM so that it could be
used in TCG mode too for non-native targets, mainly 32 bits on 64 bit
hosts and compatible page sizes etc. Then some of the generated memory
access instructions could access memory directly, bypassing the
software TLB and MMU. For those cases, at least generated instruction
count could decrease, maybe also performance. Error handling would be

> Proper disclosure: I'm fairly new to this whole cross-architecture deal.
> Yours, Lior.

reply via email to

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