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

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

[Lior Vernia]

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?

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

Yours, Lior.

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

[Blue Swirl]

On Fri, May 24, 2013 at 7:24 PM, Lior Vernia <liorvern@gmail.com> 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
hideous.

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

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

[Andreas Färber]

Hi,

Am 24.05.2013 21:24, schrieb Lior Vernia:
> I am running x86 applications on an ARM device using QEMU, and found
> it too slow for my needs.

Before we start going into technical details, what are you trying to
achieve on a high level and how did you try to do it?

Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0?

> This is to be expected, of course, this is
> not a complaint.

Especially since most people still run on x86 ...

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

... the tcg/arm/ code does not get a lot of love, so you might be able
to squeeze some more performance out of it by implementing optional TCG
ops or optimizing existing implementations. In theory most TCG ops
should correspond to a machine instruction (where available); there's a
TCG-level optimizer to create more efficient code, but it's a tradeoff
between time for code optimization and execution time.

Needless to say that you should enable -O3 optimization (or something)
for the core C code and not to enable debug features in configure for
your performance measurements. :)

Whatever implementation you experiment with, get familiar with our
Git-based workflow and try to stay close to qemu.git code or otherwise
you'll create a fork with little chance of getting integrated into the
code base - meaning both we don't get your speedups and you don't get
our latest features and bugfixes. One such example was the attempt to
use LLVM instead of TCG.

Regards,
Andreas

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Paolo Bonzini]

Il 25/05/2013 21:06, Andreas Färber ha scritto:
> Hi,
> 
> Am 24.05.2013 21:24, schrieb Lior Vernia:
>> I am running x86 applications on an ARM device using QEMU, and found
>> it too slow for my needs.
> 
> Before we start going into technical details, what are you trying to
> achieve on a high level and how did you try to do it?
> 
> Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0?

In either case, one problem would be the 64-bit operations.
qemu-system-i386 and qemu-i386 would probably be a bit faster, if you
are running 32-bit only.

Paolo

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

[Lior Vernia]

Hello,

On Sat, May 25, 2013 at 10:06 PM, Andreas Färber <afaerber@suse.de> wrote:
> Hi,
>
> Am 24.05.2013 21:24, schrieb Lior Vernia:
>> I am running x86 applications on an ARM device using QEMU, and found
>> it too slow for my needs.
>
> Before we start going into technical details, what are you trying to
> achieve on a high level and how did you try to do it?
>
> Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0?

Sorry, right after I wrote the message it occured to me I should have
mentioned that I was talking about qemu-system, either x86 or i386. At
the moment I just ran the limbo app on a Galaxy SIII with various
images, just to see the capabilities, and was disappointed. Limbo
seems to run v1.1.0.

If you suspect that it's the JNI wrapping that's causing a lot of the
damage, then we can talk about compiling QEMU for ARM and running it
natively, I just haven't been able to get that to work.

>> This is to be expected, of course, this is
>> not a complaint.
>
> Especially since most people still run on x86 ...
>
>> 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?

I wanted to add that I've been reading about this Russian startup
that's looking to emulate x86 on ARM at 40% of native speed using
dynamic binary translation (as far as I gather):
http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1
So this should be possible. And it can't be very much unlike QEMU, can it?

>
> ... the tcg/arm/ code does not get a lot of love, so you might be able
> to squeeze some more performance out of it by implementing optional TCG
> ops or optimizing existing implementations. In theory most TCG ops
> should correspond to a machine instruction (where available); there's a
> TCG-level optimizer to create more efficient code, but it's a tradeoff
> between time for code optimization and execution time.
>
> Needless to say that you should enable -O3 optimization (or something)
> for the core C code and not to enable debug features in configure for
> your performance measurements. :)
>
> Whatever implementation you experiment with, get familiar with our
> Git-based workflow and try to stay close to qemu.git code or otherwise
> you'll create a fork with little chance of getting integrated into the
> code base - meaning both we don't get your speedups and you don't get
> our latest features and bugfixes. One such example was the attempt to
> use LLVM instead of TCG.

Thanks, but we're getting slightly ahead of ourselves here :) I'd
still want to make sure that QEMU is at fault for the performance, and
if that's the case that there's potential for real improvement before
I start getting my hands dirty .

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

[Andreas Färber]

Am 26.05.2013 07:40, schrieb Lior Vernia:
> On Sat, May 25, 2013 at 10:06 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 24.05.2013 21:24, schrieb Lior Vernia:
>>> I am running x86 applications on an ARM device using QEMU, and found
>>> it too slow for my needs.
>>
>> Before we start going into technical details, what are you trying to
>> achieve on a high level and how did you try to do it?
>>
>> Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0?
> 
> Sorry, right after I wrote the message it occured to me I should have
> mentioned that I was talking about qemu-system, either x86 or i386. At
> the moment I just ran the limbo app on a Galaxy SIII with various
> images, just to see the capabilities, and was disappointed. Limbo
> seems to run v1.1.0.

First time I hear of that app... v1.1.0 is a year old, many TCG
improvements have happened since. Suggest you contact the app's author
to get that updated to v1.5.0.

http://git.qemu.org/?p=qemu.git;a=history;f=tcg/arm;hb=HEAD

> If you suspect that it's the JNI wrapping that's causing a lot of the
> damage,

The UI (drawing) code could also be a potential bottleneck - but judging
from the files it looks as if the UI were just a Java VNC client, which
probably accesses a JNI-unaffected QEMU process?

http://code.google.com/p/limbo-android/source/browse/#git%2Fsrc

> then we can talk about compiling QEMU for ARM and running it
> natively, I just haven't been able to get that to work.

That would take some of the uncertainties out of the equation, yes.

You still haven't said what it is that you would like to do with system
emulation on your ARM device: Does it need to be x86? If you just want
access to a full Linux system from Android, you might be more interested
in investigating qemu-system-arm with KVM acceleration (requires
Cortex-A15 and 3.9+ kernel) - in practice virtualization will be faster
than anything binary translation can offer.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Peter Maydell]

On 26 May 2013 06:40, Lior Vernia <liorvern@gmail.com> wrote:
> Sorry, right after I wrote the message it occured to me I should have
> mentioned that I was talking about qemu-system, either x86 or i386. At
> the moment I just ran the limbo app on a Galaxy SIII with various
> images, just to see the capabilities, and was disappointed. Limbo
> seems to run v1.1.0.

> I wanted to add that I've been reading about this Russian startup
> that's looking to emulate x86 on ARM at 40% of native speed using
> dynamic binary translation (as far as I gather):
> http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1
> So this should be possible. And it can't be very much unlike QEMU, can it?

That article suggests they're doing application-level translation,
not system-level emulation. If you:
 * design your emulation from scratch with that use case in mind
   (qemu is system emulation first with app-level as a secondary case)
 * are happy to have just one guest and one target architecture
   (this is actually mostly useful in that it reduces the set of things
   you have to test; it also lets you take shortcuts in corner cases
   for your initial implementation)
 * put more concentrated effort into emulation performance than QEMU

then you should be able to do better than qemu does currently.
You'd probably end up with something like Transitive's QuickTransit/
Rosetta.

thanks
-- PMM

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

[Gleb Natapov]

On Sun, May 26, 2013 at 10:26:04AM +0100, Peter Maydell wrote:
> On 26 May 2013 06:40, Lior Vernia <liorvern@gmail.com> wrote:
> > Sorry, right after I wrote the message it occured to me I should have
> > mentioned that I was talking about qemu-system, either x86 or i386. At
> > the moment I just ran the limbo app on a Galaxy SIII with various
> > images, just to see the capabilities, and was disappointed. Limbo
> > seems to run v1.1.0.
> 
> > I wanted to add that I've been reading about this Russian startup
> > that's looking to emulate x86 on ARM at 40% of native speed using
> > dynamic binary translation (as far as I gather):
> > http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1
> > So this should be possible. And it can't be very much unlike QEMU, can it?
> 
> That article suggests they're doing application-level translation,
> not system-level emulation. If you:
>  * design your emulation from scratch with that use case in mind
>    (qemu is system emulation first with app-level as a secondary case)
>  * are happy to have just one guest and one target architecture
>    (this is actually mostly useful in that it reduces the set of things
>    you have to test; it also lets you take shortcuts in corner cases
>    for your initial implementation)
>  * put more concentrated effort into emulation performance than QEMU
> 
> then you should be able to do better than qemu does currently.
> You'd probably end up with something like Transitive's QuickTransit/
> Rosetta.
> 
Actually here is an example of Starcraft running in android on ARM in
full speed: http://forum.xda-developers.com/showthread.php?p=39009939
Search more about winulator.

--
			Gleb.

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

[Peter Maydell]

On 26 May 2013 10:58, Gleb Natapov <gleb@redhat.com> wrote:
> Actually here is an example of Starcraft running in android on ARM in
> full speed: http://forum.xda-developers.com/showthread.php?p=39009939
> Search more about winulator.

Yes; that seems to also be taking the path of going specifically
for application level emulation (of Windows apps in this case)
with one supported guest/target combination.

-- PMM

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

[Lior Vernia]

On Sun, May 26, 2013 at 12:00 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 26.05.2013 07:40, schrieb Lior Vernia:
>> On Sat, May 25, 2013 at 10:06 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 24.05.2013 21:24, schrieb Lior Vernia:
>>>> I am running x86 applications on an ARM device using QEMU, and found
>>>> it too slow for my needs.
>>>
>>> Before we start going into technical details, what are you trying to
>>> achieve on a high level and how did you try to do it?
>>>
>>> Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0?
>>
>> Sorry, right after I wrote the message it occured to me I should have
>> mentioned that I was talking about qemu-system, either x86 or i386. At
>> the moment I just ran the limbo app on a Galaxy SIII with various
>> images, just to see the capabilities, and was disappointed. Limbo
>> seems to run v1.1.0.
>
> First time I hear of that app... v1.1.0 is a year old, many TCG
> improvements have happened since. Suggest you contact the app's author
> to get that updated to v1.5.0.
>
> http://git.qemu.org/?p=qemu.git;a=history;f=tcg/arm;hb=HEAD
>
>> If you suspect that it's the JNI wrapping that's causing a lot of the
>> damage,
>
> The UI (drawing) code could also be a potential bottleneck - but judging
> from the files it looks as if the UI were just a Java VNC client, which
> probably accesses a JNI-unaffected QEMU process?

Yes, that was my impression as well.

>
> http://code.google.com/p/limbo-android/source/browse/#git%2Fsrc
>
>> then we can talk about compiling QEMU for ARM and running it
>> natively, I just haven't been able to get that to work.
>
> That would take some of the uncertainties out of the equation, yes.

A little off-topic, so maybe I'll start a different thread on how I
tried to compile and what I got when trying to run it.

>
> You still haven't said what it is that you would like to do with system
> emulation on your ARM device: Does it need to be x86? If you just want
> access to a full Linux system from Android, you might be more interested
> in investigating qemu-system-arm with KVM acceleration (requires
> Cortex-A15 and 3.9+ kernel) - in practice virtualization will be faster
> than anything binary translation can offer.

Yes, I'm sorry if I haven't made that clear enough, the mission
statement would be to run an arbitrary x86 system image on an ARM
host. Preferably as a non-privileged user. Both of which led me to
QEMU.

Lior.

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Lior Vernia]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hi Peter,

On May 26, 2013 12:26 PM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
> On 26 May 2013 06:40, Lior Vernia <liorvern@gmail.com> wrote:
> > Sorry, right after I wrote the message it occured to me I should have
> > mentioned that I was talking about qemu-system, either x86 or i386. At
> > the moment I just ran the limbo app on a Galaxy SIII with various
> > images, just to see the capabilities, and was disappointed. Limbo
> > seems to run v1.1.0.
>
> > I wanted to add that I've been reading about this Russian startup
> > that's looking to emulate x86 on ARM at 40% of native speed using
> > dynamic binary translation (as far as I gather):
> > http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1
> > So this should be possible. And it can't be very much unlike QEMU, can
it?
>
> That article suggests they're doing application-level translation,
> not system-level emulation. If you:
>  * design your emulation from scratch with that use case in mind
>    (qemu is system emulation first with app-level as a secondary case)
>  * are happy to have just one guest and one target architecture
>    (this is actually mostly useful in that it reduces the set of things
>    you have to test; it also lets you take shortcuts in corner cases
>    for your initial implementation)
>  * put more concentrated effort into emulation performance than QEMU
>
> then you should be able to do better than qemu does currently.
> You'd probably end up with something like Transitive's QuickTransit/
> Rosetta.

What about no to the first bullet but yes to the second (just x86 on ARM)?
Any room for significant improvement in that case, starting from the
foundations of QEMU?

>
> thanks
> -- PMM

[-- Attachment #2: Type: text/html, Size: 2260 bytes --]

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

[Paolo Bonzini]

Il 26/05/2013 18:35, Lior Vernia ha scritto:
> What about no to the first bullet but yes to the second (just x86 on
> ARM)? Any room for significant improvement in that case, starting from
> the foundations of QEMU?

You could write a target-specific translator, yes.  But first of all I
would answer whether you're using 32- or 64-bit, and run some profiling
to see what is the hotspot in your case.

I know that in some scenarios helpers for SSE take a considerable amount
of time (5-10%).  You could look at adding SIMD data types to TCG, and
map them to Neon operations or even to fully-unrolled loops.

As other works, ahead-of-time translation can also do a lot more
optimizations, including very aggressive dead-code elimination.  For
example, again considering SSE, something like

     pcmpeqw  %xmm0, %xmm1
     pmovmskb %xmm1, %eax
     test     %eax, %eax
     jz       ...

will be translated to a slow sequence in QEMU due to the expensive
pmovmskb.  A custom code generator can observe that %eax is dead and use
a better translation of this idiom.

Also, floating-point emulation is always done in software in QEMU due to
different representations (and due to the 80-bit floating-point
registers mostly used by 32-bit x86).  This is going to be slow no
matter what.

Paolo