[Top][All Lists]

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

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

From: Jakob Bohm
Subject: Re: [Qemu-discuss] Issues with QEMU on Tegra K1 _HOST_.
Date: Tue, 1 Sep 2015 17:28:50 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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:


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


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

reply via email to

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