Thanks Peter .. my sincere gratitude.
You pin-pointed the real issue ..

On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <> wrote:
> On 10 April 2018 at 09:16, Ajay Garg <> wrote:
>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <> 
>> wrote:
>>> What hardware (what CPU, board, etc) is this "rumprun" software
>>> expecting to run on?
>> Yep, just to ensure that there are no cross-compiling issues, I am
>> building rumprun on the pseudo-real hardware itself.
>> In our case, the pseudo-real hardware are :
>> a)
>> An ARM32 "virt" hardware/machine in a qemu environment
>> (
>> Once I start  this machine, all environment is arm32, and I compile
>> rumprun within this environemnt without any cross-compiling.
>> b)
>> A beaglebone-green-wireless.
>> This is a arm32 machine bottoms-up, so no question of cross-compiling
>> whatsoever here :)
>> In both cases, I then use qemu-system-arm (on the "virt" machine, and
>> beaglebone-green-wireless itself).
> That's telling me what setups you're trying to compile in,
> which doesn't correspond necessarily to what the guest
> OS is built to run on.
>> One query : It is apparent that there is nested qemu-virtualization in
>> step a), could that be an issue?
> Why are you running this in a nested setup? I don't understand
> the purpose of doing that. It would be simpler and faster to
> just run the guest on a QEMU running in your native host system.
> Assuming this is the source for the guest you're trying to run:
> that suggests that the only Arm board it supports is "integrator"
> (which is an absolutely ancient devboard with very little memory,
> no PCI and no virtio support). You need to confirm what Arm hardware
> this 'rumpkernel' is actually intended to run on, and then give QEMU
> the right command line arguments to emulate that hardware. I can't
> really help any further, I'm afraid -- you need somebody who knows
> about this guest OS.
> thanks
> -- PMM


Reply via email to