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

[Ajay Garg]

Is "integratorcp" the same board that rumprun is being built for
(https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator)?

On Thu, Apr 12, 2018 at 9:56 AM, Ajay Garg <address@hidden> wrote:
> Actually just realised that qemu does support integratorcp as one of
> the supported-boards.
>
> Unfortunately, when I use
>           qemu-system-arm -machine integratorcp -nographic -kernel helloer.bin
> the shell just hangs :(
>
>
> Following are the details when run through gdb :
>
> ##########################################################################
> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabihf".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from qemu-system-arm...(no debugging symbols found)...done.
> (gdb) r
> Starting program: /usr/bin/qemu-system-arm -machine integratorcp
> -nographic -kernel helloer.bin
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> [New Thread 0xb388f290 (LWP 596)]
>
> Program received signal SIGUSR1, User defined signal 1.
> [Switching to Thread 0xb388f290 (LWP 596)]
> memset () at ../ports/sysdeps/arm/memset.S:50
> 50    ../ports/sysdeps/arm/memset.S: No such file or directory.
> (gdb) bt
> #0  memset () at ../ports/sysdeps/arm/memset.S:50
> #1  0xb65e1c6c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> ##########################################################################
>
> On Wed, Apr 11, 2018 at 12:49 PM, Ajay Garg <address@hidden> wrote:
>> Hi All.
>>
>> Just wondering if there is something specific that needs to changed at
>> https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator
>> 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,
>> Ajay
>>
>> 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
>>
>>
>>
>> --
>> Regards,
>> Ajay
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay