Не удалось запустить RTEMS как XU's DomU на QEMU - PullRequest
Новая
       101

Не удалось запустить RTEMS как XU's DomU на QEMU

0 голосов
/ 06 марта 2020

Я пытаюсь запустить RTEMS, например Xen DomU, в QEMU, но у меня возникают проблемы. Я сделал это в соответствии со следующими шагами:

  1. Настройка и сборка XEN из источника с использованием Peta Linux для xilinx-zcu102-v2019.2 BSP.
  2. Запуск Xen dom0 на QEMU из готовых изображений.
  3. Создание RTEMS для xen_virtual bsp
  4. Запуск примера RTEMS hello.exe в качестве DomU
  5. Создание файла конфигурации со следующим содержимым. 
    name = "hello"
    kernel = "hello.bin"
    memory = 8
    vcpus = 1
    gic_version = "v2"
    vuart = "sbsa_uart"

Создание виртуальной машины по команде xl create -c hello.cfg, но выполнение было не удалось : 

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@0: Disconnected clk=1115630696488 ns

Я некоторое время искал ответ и не могу найти что-нибудь. Я буду рад, если вы сможете дать мне какие-либо предложения, которые могут быть полезны в этом отношении.

...