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

[J. Scott Kasten]

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:
> >
> > http://lists.nongnu.org/archive/html/qemu-discuss/2014-05/msg00012.html
> >
> > 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?

Thanks,

-S-