RTEMS virtualization by XEN on QEMU

[Bigel Hadi]

Hello,everyone

I'm trying to run RTEMS such as Xen DomU on QEMU but I'm running into problems. 
I 've done this according to the following steps:

   
   - Configuring and building XEN from source using PetaLinux for xilinx-zcu102-v2019.2 BSP.
   - Running Xen dom0 on QEMU from pre-built images.
   - Building RTEMS for xen_virtual bsp
   - Running RTEMS's hello.exe(testsuites/samples) example as DomU   

Creating a configuration file with the following contents.

    name = "hello"
    kernel = "hello.bin"
    memory = 8
    vcpus = 1
    gic_version = "v2"
    vuart = "sbsa_uart"

Creating the virtual machine by command xl create -c hello.cfg but execution has been failed:

xilinx-zcu102-2019_2 login: (XEN) Hypervisor Trap. HSR=0x2000000 EC=0x0 IL=1 Syndrome=0x0
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) ----[ Xen-4.11.2-pre  arm64  debug=n   Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     0000000000241e68 domain.c#schedule_tail+0x288/0x2b8
(XEN) LR:     0000000000241d3c
(XEN) SP:     00008000fff27e70
(XEN) CPSR:   600002c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)      X0: 0000000000000000  X1: 0000000000000000  X2: 000000004002e0f0
(XEN)      X3: 0000000000000000  X4: 00008000ffe7d5cc  X5: 000000004002e000
(XEN)      X6: 000080004ffaf677  X7: 000000000027a000  X8: 00008000ffe7d2e0
(XEN)      X9: 00008000fff27eb0 X10: 00008000fffbbb70 X11: 000000000030fb00
(XEN)     X12: 000000000030fa20 X13: 000000bf83d650b8 X14: 00008000fff12400
(XEN)     X15: 0000000000000400 X16: 0000000000000000 X17: ffffffff00000001
(XEN)     X18: 0000000000000400 X19: 00008000fff3b000 X20: 00008000ffe7d000
(XEN)     X21: 000000000030f000 X22: 0000000000000000 X23: 0000000000000000
(XEN)     X24: 0000000000000000 X25: 0000000000000000 X26: 0000000000000000
(XEN)     X27: 0000000000000000 X28: 0000000000000000  FP: 0000000000000000
(XEN) 
(XEN)   VTCR_EL2: 80023558
(XEN)  VTTBR_EL2: 000200087ff94000
(XEN) 
(XEN)  SCTLR_EL2: 30cd187d
(XEN)    HCR_EL2: 000000000038663f
(XEN)  TTBR0_EL2: 000000087ff04000
(XEN) 
(XEN)    ESR_EL2: 02000000
(XEN)  HPFAR_EL2: 0000000000f90100
(XEN)    FAR_EL2: ffffff8008010850
(XEN) 
(XEN) Xen stack trace from sp=00008000fff27e70:
(XEN)    000000000030fc00 00008000fff3b000 0000000000000000 0000000000241ed0
(XEN)    0000000000000000 0000000000000000 0000000000241e98 0000000000000000
(XEN)    0000000000000000 00000000ffffffff 00000000407ff000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000040008000 00000000000001d3 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<0000000000241e68>] domain.c#schedule_tail+0x288/0x2b8 (PC)
(XEN)    [<0000000000241d3c>] domain.c#schedule_tail+0x15c/0x2b8 (LR)
(XEN) 
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) 
(XEN) ****************************************
(XEN) 
(XEN) Reboot in five seconds...
qemu-system-aarch64: Trying to execute code outside RAM or ROM at 0x00000000fef319dc
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed 
    on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a 
    ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line 
and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your 
guest with the -d debug options; in particular -d guest_errors will 
cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

qemu-system-microblazeel: /pmu at 0: Disconnected clk=1115630696488 ns

I searched for an answer for a while and can't find anything. 
I'll glad if you could give me any suggestions which could be helpful in this regard.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200307/d0553cfe/attachment.html>