[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: J. Scott Kasten
Subject: Re: [Qemu-discuss] Issues with QEMU on Tegra K1 _HOST_.
Date: Sat, 5 Sep 2015 11:10:06 +0800 (ULAT)
User-agent: Alpine 2.10 (DEB 1266 2009-07-14)

On Tue, 1 Sep 2015, Jakob Bohm wrote:

On 01/09/2015 15:39, address@hidden wrote:
I've looked through the mailing list and found one reference last year that seems to be the same problem:


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.

Unfortunately, this isn't simply a matter of slowness. There's some stuff really broken when hosted on ARM that work perfectly for the same VM image and same version of QEMU on an Intel host.

Some examples using QEMU 2.4.0.

* Boot AMD64 NetBSD-6.1.5 installer. Install fails because no matter what the real size of the QEMU drive is, it reports as -144GB which causes NetBSD disklabel to fail.

* Boot Linux 3.16 MIPS64 arch. System never comes up because the QEMU process goes to sleep and never wakes up (or at least only does sparingly). TOP shows the the QEMU process is accumulating only seconds of run time while hours pass by waiting for it to do something.

* Boot Linux 3.16 AMD64 arch. System basically comes up, but I see a lot of strangeness that makes it unuesable. DHCP always fails, daemon reports "illegal time values". The grep command frequently fails reporting "memory exhausted" even though top within the VM shows most of the memory free. Still fails no matter how much real memory I add to the quest.

* Boot OpenBSD 5.7 SPARC64. System highly unstable. Processes within the VM frequently and randomly "segfault".

When run on an Intel host, same QEMU 2.4.0, these images appear to work just fine. As mentioned in my previous email, I've tried some differentials I.E. gcc-4.9 vs gcc-4.8 vs gcc-4.5, QEMU 2.1.2 vs 2.2.1 vs 2.3.1 vs 2.4.0, ARM-HF vs ARM-SF, etc. But nothing has helped.

I would be interested in doing some real sluthing and debugging here to figure out what's going wrong. I'm well experienced in kernels, gcc & libc internals and such, so digging deep is not a problem. What I could use though is a few pointers on where to start looking. In a native system I wold be looking for mismatches between syscall paramters, unsaved registers in the compiler code or interrupt vectors, etc.

Perhaps there's a good suite of unit tests that might reveal some differences between an x86 and an ARM build?



reply via email to

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