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

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

[Ajay Garg]

Hi All.

We did the following :

a)
Cross-compile rumprun for ARM on a linux x86_64 :

ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
CC=arm-linux-gnueabihf-gcc ./build-rr.sh hw

b)
Compile and bake the hello-world binary

ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
arm-rumprun-netbsdelf-eabihf-gcc helloer.c -o helloer
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ rumprun-bake hw_virtio
helloer.bin helloer

The second step required changing

conf hw_virtio
    create      "virtio targets (e.g. QEMU/KVM)"
    assimilate  _miconf                      \
    _virtio
fnoc

to

conf hw_virtio
    create      "virtio targets (e.g. QEMU/KVM)"
    assimilate  _miconf
fnoc

in /home/ajay/rumprun-arm-hw/rumprun/./rumprun/etc/rumprun-bake.conf

c)
Tried running on x86_64, via qemu, but got the crash :

######################################################################
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ qemu-system-x86_64
-nographic -kernel helloer.bin
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a01f1

EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000001
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00009fde
EIP=0000fff1 EFL=00000086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =9000 00090000 ffffffff 00cf9300
CS =9020 00090200 0000ffff 00009b00
SS =9000 00090000 0000ffff 00009300
DS =9000 00090000 0000ffff 00009300
FS =9000 00090000 0000ffff 00009300
GS =9000 00090000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000cab0c 00000017
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000044 CCD=000000b4 CCO=SUBB
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
Aborted (core dumped)
######################################################################


d)
Also find below when tried with gdb :

######################################################################
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ gdb --args
qemu-system-x86_64 -nographic -nographic -kernel helloer.bin
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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 "x86_64-linux-gnu".
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-x86_64...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/qemu-system-x86_64 -nographic -nographic
-kernel helloer.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecde1700 (LWP 30356)]
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
[New Thread 0x7fffd1f2f700 (LWP 30357)]
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a01f1

EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000001
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00009fde
EIP=0000fff1 EFL=00000086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =9000 00090000 ffffffff 00cf9300
CS =9020 00090200 0000ffff 00009b00
SS =9000 00090000 0000ffff 00009300
DS =9000 00090000 0000ffff 00009300
FS =9000 00090000 0000ffff 00009300
GS =9000 00090000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000cab0c 00000017
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000044 CCD=000000b4 CCO=SUBB
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Thread 3 "qemu-system-x86" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd1f2f700 (LWP 30357)]
0x00007ffff2b74428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff2b74428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff2b7602a in __GI_abort () at abort.c:89
#2  0x000055555573d33d in cpu_abort ()
#3  0x0000555555781fdd in get_page_addr_code ()
#4  0x0000555555743d63 in ?? ()
#5  0x000055555574485b in cpu_x86_exec ()
#6  0x0000555555765fb2 in ?? ()
#7  0x00007ffff2f106ba in start_thread (arg=0x7fffd1f2f700) at
pthread_create.c:333
#8  0x00007ffff2c4641d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)
######################################################################


Where should we be looking to start to fix?



Thanks and Regards,
Ajay

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

[Alex Bennée]

Ajay Garg <ajaygargnsit@gmail.com> writes:

> Hi All.
>
> We did the following :
>
> a)
> Cross-compile rumprun for ARM on a linux x86_64 :
>
> ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
> CC=arm-linux-gnueabihf-gcc ./build-rr.sh hw
<snip>
>
> c)
> Tried running on x86_64, via qemu, but got the crash :
>
> ######################################################################
> ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ qemu-system-x86_64
> -nographic -kernel helloer.bin
> warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a01f1
>
<snip>
>
>
> Where should we be looking to start to fix?

qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
qemu-system-arm. More importantly you need to specify a -M machine type
that matches whatever rumprun is expecting.

--
Alex Bennée

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

[Ajay Garg]

>
> qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
> qemu-system-arm. More importantly you need to specify a -M machine type
> that matches whatever rumprun is expecting.
>

Oops, sorry my bad.
Here is the updated status :

ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ qemu-system-arm -machine
virt -nographic -nographic -kernel helloer.bin
Bad ram pointer 0x1e8
Aborted (core dumped)


ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ gdb --args
qemu-system-arm -machine virt -nographic -nographic -kernel
helloer.bin
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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 "x86_64-linux-gnu".
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 virt -nographic
-nographic -kernel helloer.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecc88700 (LWP 14033)]
[New Thread 0x7fffd21fc700 (LWP 14034)]
Bad ram pointer 0x1e8

Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd21fc700 (LWP 14034)]
0x00007ffff2a1b428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff2a1b428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff2a1d02a in __GI_abort () at abort.c:89
#2  0x00005555557687f1 in get_page_addr_code ()
#3  0x000055555572d50c in ?? ()
#4  0x000055555572e11b in cpu_arm_exec ()
#5  0x0000555555750252 in ?? ()
#6  0x00007ffff2db76ba in start_thread (arg=0x7fffd21fc700) at
pthread_create.c:333
#7  0x00007ffff2aed41d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)


Thanks and Regards,
Ajay

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

[Alex Bennée]

Ajay Garg <ajaygargnsit@gmail.com> writes:

>>
>> qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
>> qemu-system-arm. More importantly you need to specify a -M machine type
>> that matches whatever rumprun is expecting.
>>
>
> Oops, sorry my bad.
> Here is the updated status :
>
> ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ qemu-system-arm -machine
> virt -nographic -nographic -kernel helloer.bin
> Bad ram pointer 0x1e8
> Aborted (core dumped)

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.

>
>
> ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ gdb --args
> qemu-system-arm -machine virt -nographic -nographic -kernel
> helloer.bin
> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
> Copyright (C) 2016 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 "x86_64-linux-gnu".
> 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 virt -nographic
> -nographic -kernel helloer.bin
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffecc88700 (LWP 14033)]
> [New Thread 0x7fffd21fc700 (LWP 14034)]
> Bad ram pointer 0x1e8
>
> Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffd21fc700 (LWP 14034)]
> 0x00007ffff2a1b428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff2a1b428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x00007ffff2a1d02a in __GI_abort () at abort.c:89
> #2  0x00005555557687f1 in get_page_addr_code ()
> #3  0x000055555572d50c in ?? ()
> #4  0x000055555572e11b in cpu_arm_exec ()
> #5  0x0000555555750252 in ?? ()
> #6  0x00007ffff2db76ba in start_thread (arg=0x7fffd21fc700) at
> pthread_create.c:333
> #7  0x00007ffff2aed41d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> (gdb)
>
>
> Thanks and Regards,
> Ajay


--
Alex Bennée

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

[Ajay Garg]

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.
Finally, upon running, I now get this :

##########################################################################################
ajay@debian:~/rumprun-arm32$ qemu-system-arm -machine virt -nographic
-kernel helloer.bin
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00100000

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00100000
PSR=400001d3 -Z-- A svc32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000
Aborted
##########################################################################################


Additionally, I compiled rumprun on a beaglebone-green-wireless (arm32
machine), and did the same test.
(Fortunately), I got the exact same stacktrace as above, so I guess
it's no more  an issue with hardware-mismatch now ..

Not sure if this is an issue with qemu now, or rumprun ...


Thanks and Regards,
Ajay

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

[Ajay Garg]

Following is the gdb details :

##########################################################################################
ajay@debian:~/rumprun-arm32$ gdb --args qemu-system-arm -machine virt
-nographic -kernel helloer.bin
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 virt -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 3140)]
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00100000

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb388f290 (LWP 3140)]
0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
81    ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
#1  0xb5e45c84 in _IO_new_file_write (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=0xb388c5a0, n=12) at fileops.c:1253
#2  0xb5e454b2 in new_do_write (fp=fp@entry=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=data@entry=0xb388c5a0 "R04=00000000", to_do=to_do@entry=12)
    at fileops.c:530
#3  0xb5e460d0 in _IO_new_file_xsputn (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=<optimized out>, n=12) at fileops.c:1335
#4  0xb5e2bc8e in buffered_vfprintf (s=s@entry=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=format@entry=0x263e68 "R%02d=%08x", args=...) at vfprintf.c:2369
#5  0xb5e28418 in _IO_vfprintf_internal (s=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=0x263e68 "R%02d=%08x", format@entry=0x84ad60 "pg\201", ap=...,
    ap@entry=...) at vfprintf.c:1296
#6  0xb5e2ee00 in __fprintf (stream=<optimized out>,
    format=0x263e68 "R%02d=%08x") at fprintf.c:32
#7  0x000dc352 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
#0  0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
#1  0xb5e45c84 in _IO_new_file_write (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=0xb388c5a0, n=12) at fileops.c:1253
#2  0xb5e454b2 in new_do_write (fp=fp@entry=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=data@entry=0xb388c5a0 "R04=00000000", to_do=to_do@entry=12)
    at fileops.c:530
#3  0xb5e460d0 in _IO_new_file_xsputn (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=<optimized out>, n=12) at fileops.c:1335
#4  0xb5e2bc8e in buffered_vfprintf (s=s@entry=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=format@entry=0x263e68 "R%02d=%08x", args=...) at vfprintf.c:2369
#5  0xb5e28418 in _IO_vfprintf_internal (s=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=0x263e68 "R%02d=%08x", format@entry=0x84ad60 "pg\201", ap=...,
    ap@entry=...) at vfprintf.c:1296
#6  0xb5e2ee00 in __fprintf (stream=<optimized out>,
    format=0x263e68 "R%02d=%08x") at fprintf.c:32
#7  0x000dc352 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
##########################################################################################

On Tue, Apr 10, 2018 at 9:44 AM, Ajay Garg <ajaygargnsit@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.
> Finally, upon running, I now get this :
>
> ##########################################################################################
> ajay@debian:~/rumprun-arm32$ qemu-system-arm -machine virt -nographic
> -kernel helloer.bin
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x00100000
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=00000000 R14=00000000 R15=00100000
> PSR=400001d3 -Z-- A svc32
> s00=00000000 s01=00000000 d00=0000000000000000
> s02=00000000 s03=00000000 d01=0000000000000000
> s04=00000000 s05=00000000 d02=0000000000000000
> s06=00000000 s07=00000000 d03=0000000000000000
> s08=00000000 s09=00000000 d04=0000000000000000
> s10=00000000 s11=00000000 d05=0000000000000000
> s12=00000000 s13=00000000 d06=0000000000000000
> s14=00000000 s15=00000000 d07=0000000000000000
> s16=00000000 s17=00000000 d08=0000000000000000
> s18=00000000 s19=00000000 d09=0000000000000000
> s20=00000000 s21=00000000 d10=0000000000000000
> s22=00000000 s23=00000000 d11=0000000000000000
> s24=00000000 s25=00000000 d12=0000000000000000
> s26=00000000 s27=00000000 d13=0000000000000000
> s28=00000000 s29=00000000 d14=0000000000000000
> s30=00000000 s31=00000000 d15=0000000000000000
> s32=00000000 s33=00000000 d16=0000000000000000
> s34=00000000 s35=00000000 d17=0000000000000000
> s36=00000000 s37=00000000 d18=0000000000000000
> s38=00000000 s39=00000000 d19=0000000000000000
> s40=00000000 s41=00000000 d20=0000000000000000
> s42=00000000 s43=00000000 d21=0000000000000000
> s44=00000000 s45=00000000 d22=0000000000000000
> s46=00000000 s47=00000000 d23=0000000000000000
> s48=00000000 s49=00000000 d24=0000000000000000
> s50=00000000 s51=00000000 d25=0000000000000000
> s52=00000000 s53=00000000 d26=0000000000000000
> s54=00000000 s55=00000000 d27=0000000000000000
> s56=00000000 s57=00000000 d28=0000000000000000
> s58=00000000 s59=00000000 d29=0000000000000000
> s60=00000000 s61=00000000 d30=0000000000000000
> s62=00000000 s63=00000000 d31=0000000000000000
> FPSCR: 00000000
> Aborted
> ##########################################################################################
>
>
> Additionally, I compiled rumprun on a beaglebone-green-wireless (arm32
> machine), and did the same test.
> (Fortunately), I got the exact same stacktrace as above, so I guess
> it's no more  an issue with hardware-mismatch now ..
>
> Not sure if this is an issue with qemu now, or rumprun ...
>
>
> Thanks and Regards,
> Ajay



-- 
Regards,
Ajay

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

[Peter Maydell]

On 10 April 2018 at 05:14, Ajay Garg <ajaygargnsit@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

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

[Ajay Garg]

Hi Peter.

Thanks for the reply.

On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 10 April 2018 at 05:14, Ajay Garg <ajaygargnsit@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?

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).


One query : It is apparent that there is nested qemu-virtualization in
step a), could that be an issue?


>
> (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



-- 
Regards,
Ajay

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

[Peter Maydell]

On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@gmail.com> wrote:
> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> 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

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

[Ajay Garg]

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



On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@gmail.com> wrote:
>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> 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

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

[Ajay Garg]

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 <ajaygargnsit@gmail.com> wrote:
> Thanks Peter .. my sincere gratitude.
> You pin-pointed the real issue ..
>
>
>
> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@gmail.com> wrote:
>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> 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

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

[Ajay Garg]

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 <ajaygargnsit@gmail.com> 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 <ajaygargnsit@gmail.com> wrote:
>> Thanks Peter .. my sincere gratitude.
>> You pin-pointed the real issue ..
>>
>>
>>
>> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@gmail.com> wrote:
>>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> 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

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 <ajaygargnsit@gmail.com> 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 <ajaygargnsit@gmail.com> 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 <ajaygargnsit@gmail.com> wrote:
>>> Thanks Peter .. my sincere gratitude.
>>> You pin-pointed the real issue ..
>>>
>>>
>>>
>>> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@gmail.com> wrote:
>>>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@linaro.org> 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