[Top][All Lists]

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

Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for

From: Ajay Garg
Subject: Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for ARM
Date: Wed, 11 Apr 2018 12:49:27 +0530

Hi All.

Just wondering if there is something specific that needs to changed at
in order to get a hello-world app run on "virt" machine?

If so, I would request the rumprun-guys to kindly throw in some light,
on what needs to be done in order to have something run on a "virt"
machine in qemu-context.

Thanks and Regards,

On Tue, Apr 10, 2018 at 3:49 PM, Ajay Garg <address@hidden> wrote:
> Thanks Peter .. my sincere gratitude.
> You pin-pointed the real issue ..
> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <address@hidden> wrote:
>> On 10 April 2018 at 09:16, Ajay Garg <address@hidden> wrote:
>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <address@hidden> 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
>>> (https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/)
>>> 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:
>> https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch
>> 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
> --
> Regards,
> Ajay


reply via email to

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