Re: [Qemu-devel] Project: x86 to ARM binary translator

[Blue Swirl]

On Sat, Apr 2, 2011 at 3:12 AM, Yale Zhang <address@hidden> wrote:
> Fellow developers,
> I'm thinking of starting a VM project to allow running x86 Windows apps on
> ARM Android. This will obviously involve binary translation. I've read about
> QEMU's  tiny code generator and think for a usable experience,
>  the intermediate micro-op representation will have to be abandoned, and use
> a more efficient, though less portable x86 to ARM translator. I also saw
> some Google SOC project that tried to incorporate LLVM into QEMU, but with
> disastrous slow down if done naively. I still think it's worth to do so, but
> lots of care will need to be done to only optimize code that needs it like
> Sun's HotSpot Java compiler does.

What problems have you spotted with TCG? I'm pretty sure it's easier
to fix those than to start from scratch.

There are also ways to speed up cross target emulation which haven't
been used so far because of effort needed and lack of interest. For
example, currently softmmu targets without KVM use (as the name says)
a software emulated MMU, which slows down all loads and stores. A
hybrid of KVM and TCG could be used, so that the translated code uses
hardware MMU which makes accesses much simpler.

> Questions:
> 1. How useful would this be and how much interest?
>    Obviously, this will be a huge project, and I just want to gauge the
> interest before I jump in. Microsoft will be releasing Windows for ARM soon,
> so there will be no need to worry about
>    running Office, Matlab, Visual C++, etc on ARM, leaving only legacy
> applications and games to benefit from binary translation. I'm mostly
> interested in seeing some 3D games run on my
>    Xoom.

3D is another problem, which hasn't been solved well yet for even KVM
accelerated case. I think Spice is going to this direction.

> 2. What's the best design:  whole system VM (qemu) or process VM (qemu &
> wine)?
> Process VM:
> + easier to incorporate 3D acceleration at API level
> + uses less memory
> + better performance (e.g. no need for MMU translation when accessing
> memory)
> + much better integration with host OS
> - needs to maintain custom Windows API implementation (Wine)

The ABI (not API) is also a moving target, after DirectX 11 there will
be DirectX 12 etc.

IIRC there was a similar project for PPC once but it was abandoned.

> Whole system VM:
> + simpler, more unified to implement
> + much better support for apps that are dependent on new, proprietary,
> obscure Windows libraries, interfaces    (moot because Office, Matlab, etc
> will soon be available for ARM)
>
> Given the aims of only running legacy applications and games, it seems a
> foregone conclusion that Wine's process VM approach is best. Comments?

I think system emulation (maybe enhanced) is the most realistic choice.