On 10 April 2018 at 05:14, Ajay Garg <ajaygargn...@gmail.com> wrote: > Thanks Alex for the reply .. > >> >> Can you run under -s -S and gdb step the *guest* and see where it ends >> up. The above error is usually indicative of the guest going off into >> the weeds somewhere because the hardware isn't what it expects. >> > > So, after your reply that it might be because of the > hardware-mismatch, I kinda took a detour, and installed a arm32 "virt" > machine on qemu on a x86_64 host, as per the steps at > https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ > > All went fine, and then I compiled rumprun on this "virt" guest.
The host system hardware doesn't matter (except that if you're running suitable matching host and guest hardware you might be able to use hardware acceleration with KVM, but for the moment I would recommend concentrating on getting it working). What matters is that the guest software you run must match the hardware that you are asking QEMU to emulate. (I guess if rumprun automatically configures itself based on the system you're compiling it on then you're running a different binary, but surely it has a setup for manually configuring it when you're cross-compiling it?) What hardware (what CPU, board, etc) is this "rumprun" software expecting to run on? (The "Trying to execute code outside RAM or ROM at 0x00100000" symptoms very frequently mean "guest binary was not built to run on this emulated hardware".) thanks -- PMM
