Re: [Qemu-discuss] Issues with QEMU on Tegra K1 _HOST_.

[Jakob Bohm]

On 01/09/2015 15:39, address@hidden wrote:
> Hi guys,  I'm hoping maybe some of you have some information on a problem that 
> I am seeing.
>
> I have tried using QEMU on an ARM host, specifically a Tegra K1, and have found 
> it almost completely unusable. Usually the guest OS hangs and never frees up.  
> Sometimes the guest starts reporting errors or crashes in quest applications 
> that doesn't happen using the same guest on a non-ARM host.
>
> I've looked through the mailing list and found one reference last year that 
> seems to be the same problem:
>
> http://lists.nongnu.org/archive/html/qemu-discuss/2014-05/msg00012.html
>
>
> I have tried many things to narrow this down, but nothing has helped.  I've 
> tried building QEMU versions 2.1.2, 2.2.1, 2.3.1, and 2.4.0.  I've tried 
> compiling QEMU on the Debian ARMHF arch (hard float), and the plain (soft 
> float) ARM arch.  I've tried versions of GCC from 4.1, 4.5, 4.8, and 4.9.  I've 
> tried guests from Debian, NetBSD, OpenBSD, MIPS64, x86_64, and SPARC64.
>
> NONE of this has worked to produce even a single usable VM image.  I've tried 
> "formulas" found in various places on the web for versions of QEMU, guest OS, 
> arch, and emulated device selection.  All to no avail.  Yet I can take one of these 
> formulas to an x86 host and it will work strait away.
>
> The gist is that _something_ is horribly broken when qemu is used on an ARM 
> host.  I'm open to any suggestions that anyone might have.

One important thing you may have overlooked: When using
qemu to emulate a completely different kind of CPU (x86
on ARM or ARM on x86), things will be a lot slower
because each foreign instruction is translated to a
sequence of (often multiple) native instructions, and
every jump or call triggers a complex mechanism which
tries to find the cached translation of the jump/call
destination code, and create it if not found.

On the other hand when using qemu to emulate an
identical CPU (Armv7a w/VFP on Armv7a w/VFP or
x86-intel-core-i5-4210 on x86-intel-core-i5-4210), most
of the code can be run directly, with qemu (and its kvm
helper) just doing the sandboxing (and device I/O
emulation).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded