How do I get zephyr-domU working with xen? #42

mengtanhzc · 2024-09-10T03:39:52Z

Hello dear community.
I am currently booting xen with qemu, linux as dom0 and trying zephyr domU.

According to the Zephyr documentation( https://docs.zephyrproject.org/latest/boards/xen/xenvm/doc/index.html), I tried to run the basic Zephyr sample, but nothing works and it causes qemu to hang (can't switch to the qemu monitor via Ctrl-a c).

qemu-aarch64 ~ # xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----      43.4

qemu-aarch64 ~ # cat zephyr.conf
kernel="zephyr.bin"
name="zephyr"
vcpus=1
memory=16
gic_version="v3"
on_crash="preserve"

qemu-aarch64 ~ # xl create -c zephyr.conf
Parsing config from zephyr.conf
libxl: info: libxl_create.c:122:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory

### Qemu hang.........

I tried helloworld_xen-arm64 provided by meta-xt-prod-devel-rpi5. It works fine, and xen prints debug logs.

qemu-aarch64 ~ # cat helloworld.conf
kernel="helloworld_xen-arm64"
name="helloworld_xen-arm64"
vcpus=1
memory=16
gic_version="v3"
on_crash="preserve"

qemu-aarch64 ~ # xl create -c helloworld.conf
Parsing config from helloworld.conf
libxl: info: libxl_create.c:122:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
dbg:  [libxenplat] hv_console @ 0xffffffbfffc00000 (evtchn: 2)
dbg:  [libukboot] Call constructor: 0xffffffc000010630())...
dbg:  [libukboot] Call constructor: 0xffffffc000015768())...
dbg:  [libukboot] Call constructor: 0xffffffc000041784())...
dbg:  [libukboot] Call constructor: 0xffffffc00005d864())...
dbg:  [libukboot] Call constructor: 0xffffffc0000087cc())...
dbg:  [libukbus] Register bus handler: 0xffffffc0000a1178
dbg:  [libukboot] Trying 0xffffffc0000d9000-0xffffffc000fff000 0x00
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc0000db000 - ffffffc0000dc000 (order 0)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc0000dc000 - ffffffc0000e0000 (order 2)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc0000e0000 - ffffffc000100000 (order 5)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000100000 - ffffffc000200000 (order 8)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000200000 - ffffffc000400000 (order 9)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000400000 - ffffffc000800000 (order 10)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000800000 - ffffffc000c00000 (order 10)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000c00000 - ffffffc000e00000 (order 9)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000e00000 - ffffffc000f00000 (order 8)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000f00000 - ffffffc000f80000 (order 7)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000f80000 - ffffffc000fc0000 (order 6)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000fc0000 - ffffffc000fe0000 (order 5)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000fe0000 - ffffffc000ff0000 (order 4)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000ff0000 - ffffffc000ff8000 (order 3)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000ff8000 - ffffffc000ffc000 (order 2)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000ffc000 - ffffffc000ffe000 (order 1)
dbg:  [libukallocbbuddy] ffffffc0000d9000: Add allocate unit ffffffc000ffe000 - ffffffc000fff000 (order 0)
dbg:  [libxenplat] FDT suggests grant table base 38000000
dbg:  [libxenplat] map_gnttab, phys = 0x38000000
dbg:  [libcontext] tls_area_init: target: 0xffffffc000ffe020 (312 bytes)
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: tcb: 16 bytes
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: copy (.tdata): 0 bytes
dbg:  [libcontext] tls_area_init: uninitialized (.tbss): 0 bytes
dbg:  [libcontext] (tls_area): ffffffc000ffe020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
dbg:  [libcontext] *
dbg:  [libuksched] uk_thread 0xffffffc0000db0b0 (idle): ctx:0xffffffc0000db0b0, ectx:0xffffffc000ffc160, tlsp:0xffffffc000ffc020
dbg:  [libcontext] tls_area_init: target: 0xffffffc000ffc020 (312 bytes)
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: tcb: 16 bytes
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: copy (.tdata): 0 bytes
dbg:  [libcontext] tls_area_init: uninitialized (.tbss): 0 bytes
dbg:  [libcontext] (tls_area): ffffffc000ffc020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
dbg:  [libcontext] *
dbg:  [libcontext] ukarch_ctx 0xffffffc0000db0b0: entry:0xffffffc000049fd8(ffffffc0000db018), sp:0xffffffc000fd0020
dbg:  [libuksched] uk_thread 0xffffffc000ffd018 (init): ctx:0xffffffc000ffd018, ectx:0xffffffc000ffd0d0, tlsp:0xffffffc000ffe020
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libukboot] Call init function: 0xffffffc00002f2cc()...
dbg:  [libukboot] Call init function: 0xffffffc00004cacc()...
dbg:  [libvfscore] (int) uk_syscall_r_dup2((int) 0x0, (int) 0x1)
dbg:  [libvfscore] (int) uk_syscall_r_dup3((int) 0x0, (int) 0x1, (int) 0x0)
dbg:  [libvfscore] (int) uk_syscall_r_dup2((int) 0x0, (int) 0x2)
dbg:  [libvfscore] (int) uk_syscall_r_dup3((int) 0x0, (int) 0x2, (int) 0x0)
dbg:  [libukboot] Call init function: 0xffffffc00004ace4()...
dbg:  [libukboot] Call init function: 0xffffffc00003b020()...
dbg:  [libukbus] Initialize bus handler 0xffffffc0000a1178...
dbg:  [libuksched] uk_thread 0xffffffc000ff8018 (xenstore): ctx:0xffffffc000ff8018, ectx:0xffffffc000ff9160, tlsp:0xffffffc000ff9020
dbg:  [libcontext] tls_area_init: target: 0xffffffc000ff9020 (312 bytes)
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: tcb: 16 bytes
dbg:  [libcontext] tls_area_init: pad: 0 bytes
dbg:  [libcontext] tls_area_init: copy (.tdata): 0 bytes
dbg:  [libcontext] tls_area_init: uninitialized (.tbss): 0 bytes
dbg:  [libcontext] (tls_area): ffffffc000ff9020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
dbg:  [libcontext] *
dbg:  [libcontext] ukarch_ctx 0xffffffc000ff8018: entry:0xffffffc00000ae14(0), sp:0xffffffc0000f0020
dbg:  [libukbus] Probe bus 0xffffffc0000a1178...
dbg:  [libxenbus] Complete main loop of xs_msg_write.
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxenbus] Rsp_cons 0, rsp_prod 24.
dbg:  [libxenbus] Msg len 24, 24 avail, id 0.
dbg:  [libxenbus] Message is good.
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxenbus] Rsp_cons 24, rsp_prod 24.
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
Powered by
o.   .o       _ _               __ _
Oo   Oo  ___ (_) | __ __  __ _ ' _) :_
oO   oO ' _ `| | |/ /  _)' _` | |_|  _)
oOo oOO| | | | |   (| | | (_) |  _) :_
 OoOoO ._, ._:_:_,\_._,  .__,_:_, \___)
             Epimetheus 0.12.0~d25310a4
dbg:  [libxengic] EL1 IRQ#31 caught
dbg:  [libxengic] EL1 IRQ#1023 caught
Hello world!
Arguments:  "helloworld" "helloworld"

      _
    c'_'o  .--'
    (| |)_/            dbg:  [libxengic] EL1 IRQ#31 caught

But I haven't found the source code for helloworld_xen-arm64. So it's not clear how it works.
Is it possible that zephyr's memory address layout conflicts with qemu? Do you have any suggestions for this problem?

Thanks a lot!

The text was updated successfully, but these errors were encountered:

GrygiriiS · 2024-09-10T05:34:58Z

Regarding helloworld_xen-arm64 you can find more info here
https://github.com/xen-troops/meta-xt-rpi5/wiki/Unikraft-Xen-helloworld

Regarding zephyr.bin - it'd nice if you describe how have you got zephyr.bin?
Note. You use case is not exactly related to this project, but we'd try to help.

firscity · 2024-09-10T06:34:25Z

@mengtanhzc I have suggestions, that your issue is caused by old bug in qemu timer handling. We had this problem also with Zephyr Dom0 and tried to upstream a patch, but maintainers prepared their own and added it in mainline.

You can check this and verify if your Qemu version contains it - https://patchew.org/QEMU/[email protected]/

mengtanhzc · 2024-09-10T06:55:06Z

Regarding helloworld_xen-arm64 you can find more info here https://github.com/xen-troops/meta-xt-rpi5/wiki/Unikraft-Xen-helloworld

Regarding zephyr.bin - it'd nice if you describe how have you got zephyr.bin? Note. You use case is not exactly related to this project, but we'd try to help.

Many thanks!! I'm new to Xen and using it on Qemu for now. I'll try meta-xt on RPI later.

Here's how I built zephyr:

$ git clone https://github.com/zephyrproject-rtos/zephyr.git

$ west build -b xenvm//gicv3 samples/synchronization
# got zephyr.bin and zephyr.elf

$ cd build/zephyr/
$ readelf -lW zephyr.elf

Elf file type is EXEC (Executable file)
Entry point 0x400010bc
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x001000 0x0000000040000000 0x0000000040000000 0x009050 0x036000 RWE 0x1000
  TLS            0x008ff8 0x0000000040007ff8 0x0000000040007ff8 0x000000 0x000008 R   0x8

 Section to Segment mapping:
  Segment Sections...
   00     text initlevel device_area sw_isr_table _static_thread_data_area rodata datas device_states k_sem_area bss noinit .last_ram_section
   01     tbss

I didn't change the boards/xen/xenvm/xenvm.dts, so the memory layout is the same.

And here is the relevant configuration for qemu:

qemu-system-aarch64 \
-device qemu-xhci -device usb-tablet -device usb-kbd \
-device loader,file=Image,addr=0x45000000 \
-machine virt,gic-version=3 -machine virtualization=true -cpu cortex-a53 -smp 4 -m 1024 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci \
-kernel xen-qemu-aarch64 \
-initrd rootfs.cpio.gz \
-append 'root=/dev/ram0 rw console=hvc0' \
-dtb qemuboot.dtb

here is the qemuboot.dtb: https://gist.github.com/mengtanhzc/1b180cc65335aad93fb86f727eaeb0cd

mengtanhzc · 2024-09-10T07:42:10Z

@mengtanhzc I have suggestions, that your issue is caused by old bug in qemu timer handling. We had this problem also with Zephyr Dom0 and tried to upstream a patch, but maintainers prepared their own and added it in mainline.

You can check this and verify if your Qemu version contains it - https://patchew.org/QEMU/[email protected]/

Thanks for the key info!
After using QEMU version 8.1(which includes this bugfix), starting zephyr-domU does not cause QEMU to hang.

However, the output of zephyr is still not visible. It seems to be in a "blocked" state:

qemu-aarch64 ~ # xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----     164.2
zephyr                                       2    16     1     -b----      83.4

mengtanhzc · 2024-09-11T09:34:06Z

Regarding helloworld_xen-arm64 you can find more info here https://github.com/xen-troops/meta-xt-rpi5/wiki/Unikraft-Xen-helloworld

Regarding zephyr.bin - it'd nice if you describe how have you got zephyr.bin? Note. You use case is not exactly related to this project, but we'd try to help.

Hi, I followed the wiki you gave and built the helloworld_xen-arm64. But it throws an exception at mask_evtchn()<plat/xen/events.c @ 210>.

log:

(d2) [    0.000000] dbg:  {r:0xffffffc00001f954,f:0xffffffc000044ce0} [libukofw] <fdt.c @  224> reached root node
(d2) [    0.000000] dbg:  {r:0xffffffc00001f954,f:0xffffffc000044ce0} [libukofw] <fdt.c @  224> reached root node
(d2) [    0.000000] Info: {r:0xffffffc000021df4,f:0xffffffc000044e10} [libukintctlr_gic] <gic-v3.c @  768> Found GICv3 on:
(d2) [    0.000000] Info: {r:0xffffffc000021e1c,f:0xffffffc000044e10} [libukintctlr_gic] <gic-v3.c @  769>      Distributor  : 0xffffffbfffa01000 - 0xffffffbfffa10fff
(d2) [    0.000000] Info: {r:0xffffffc000021e44,f:0xffffffc000044e10} [libukintctlr_gic] <gic-v3.c @  771>      Redistributor: 0xffffffbfffa20000 - 0xffffffc000a1ffff
(d2) [    0.000000] Info: {r:0xffffffc0000219a4,f:0xffffffc000044e60} [libukintctlr_gic] <gic-v3.c @  473> GICv3 Max interrupt lines: 32
(d2) [    0.000000] Info: {r:0xffffffc000021a9c,f:0xffffffc000044e60} [libukintctlr_gic] <gic-v3.c @  512> GICv3 distributor initialized.
(XEN) d2v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0
(d2) [    0.000000] Info: {r:0xffffffc000021c20,f:0xffffffc000044e60} [libukintctlr_gic] <gic-v3.c @  456> GICv3 redistributor initialized.
(d2) [    0.000000] CRIT: {r:0xffffffc0000055e8,f:0xffffffc000044d40} [libxenplat] <traps_arm64.c @  210> EL1 sync trap caught
(d2) [    0.000000] CRIT: {r:0xffffffc0000053c0,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  171>        SP       : 0xffffffc000044f40
(d2) [    0.000000] CRIT: {r:0xffffffc0000053e0,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  172>        ESR_EL1  : 0x00000000600001c5
(d2) [    0.000000] CRIT: {r:0xffffffc000005400,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  173>        ELR_EL1  : 0xffffffc000044f20
(d2) [    0.000000] CRIT: {r:0xffffffc000005420,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  174>        LR (x30) : 0xffffffc0000069f4
(d2) [    0.000000] CRIT: {r:0xffffffc000005440,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  175>        PSTATE   : 0xffffffc000006a30
(d2) [    0.000000] CRIT: {r:0xffffffc000005470,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  176>        FAR_EL1  : 0xffffffc000006420
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x00 ~ x03: 0xffffffc000033230 0xffffffc000006420 0x0000000000000000 0x0000000000000001
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x04 ~ x07: 0xffffffc000068678 0xffffffc000048530 0x0000000000000001 0xffffffc000044bcb
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x08 ~ x11: 0x00000000ffffffff 0x00000000fffffffc 0x0000000000000000 0x00000000fffffffd
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x12 ~ x15: 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000000000a
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x16 ~ x19: 0x00000000deadbeef 0x00000000000000cf 0x0000000000000000 0xffffffc0000282f8
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x20 ~ x23: 0x000000000000001c 0xffffffc000048090 0x000000000000001c 0xffffffc000027a88
(d2) [    0.000000] CRIT: {r:0xffffffc0000054b4,f:0xffffffc000044ce0} [libxenplat] <traps_arm64.c @  179>        x24 ~ x27: 0xffffffc000fff000 0xffffffc000045330 0xffffffc000044fdc 0x0000000000000f6b
(d2) [    0.000000] CRIT: {r:0xffffffc0000055f4,f:0xffffffc000044d40} [libxenplat] <traps_arm64.c @  183>        x28 ~ x29: 0x0000000000000000 0xffffffc000044f20

plat/xen/events.c

/*
 * Initially all events are without a handler and disabled
 */
void init_events(void)
{
	int i;

	/* initialize event handler */
	for (i = 0; i < NR_EVS; i++) {
209		ev_actions[i].handler = default_handler;
210>>		mask_evtchn(i);    // exception...
211	}
	uk_pr_debug("hzc debug init_events..before arch init...\n");
	arch_init_events();
	uk_pr_debug("hzc debug 33333..after arch init...\n");
}

Do you still have the .config file? I want to compare them. Thanks a lot!

GrygiriiS · 2024-09-11T13:04:55Z

Try gic_version="v2"

Also I've updated wiki.

mengtanhzc · 2024-10-08T10:28:22Z

Try gic_version="v2"

Also I've updated wiki.

I modified it to gicv2 and booted with qemu with gicv2 and it still doesn't work.

qemu-aarch64 ~ # dmesg | grep GIC
[    0.000000] GICv2m: DT overriding V2M MSI_TYPER (base:80, num:64)
[    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
qemu-aarch64 ~ # ls
helloworld_xen-arm64
qemu-aarch64 ~ # vi helloworld.conf
qemu-aarch64 ~ # xl create -c helloworld.conf
Parsing config from helloworld.conf
libxl: info: libxl_create.c:122:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
(XEN) printk: 2 messages suppressed.
(XEN) d1v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0
qemu-aarch64 ~ #
qemu-aarch64 ~ #
qemu-aarch64 ~ #
qemu-aarch64 ~ # cat helloworld.conf
kernel="helloworld_xen-arm64"
name="helloworld_xen-arm64"
vcpus=1
memory=16
gic_version="v2"
on_crash="preserve"
qemu-aarch64 ~ # cat helloworld.conf
kernel="helloworld_xen-arm64"
name="helloworld_xen-arm64"
vcpus=1
memory=16
gic_version="v2"
on_crash="preserve"

And I was previously using QEMU(GICv3) to try the helloworld_xen-arm64 provided by meta-xt-prod-devel-rpi5.

Furthermore, I would be grateful if you could provide me with additional information about Xen. I'm wondering if it's possible to use UEFI+GRUB+XEN on an ARM64 board?

mengtanhzc · 2024-10-08T11:23:17Z

@mengtanhzc I have suggestions, that your issue is caused by old bug in qemu timer handling. We had this problem also with Zephyr Dom0 and tried to upstream a patch, but maintainers prepared their own and added it in mainline.

You can check this and verify if your Qemu version contains it - https://patchew.org/QEMU/[email protected]/

Hello. Have you encountered the following problem?

I modified the RAM area of Zephyr:

$ git diff .
diff --git a/boards/xen/xenvm/xenvm.dts b/boards/xen/xenvm/xenvm.dts
index bbba268d9a3..eb477b8bc2b 100644
--- a/boards/xen/xenvm/xenvm.dts
+++ b/boards/xen/xenvm/xenvm.dts
@@ -46,9 +46,9 @@
                method = "hvc";
        };

-       ram: memory@40000000 {
+       ram: memory@70000000 {
                device_type = "mmio-sram";
-               reg = <0x00 0x40000000 0x00 DT_SIZE_M(16)>;
+               reg = <0x00 0x70000000 0x00 DT_SIZE_M(16)>;
        };

        gic: interrupt-controller@3001000 {

and now I get an error when I run it.

qemu-aarch64 ~ # cat zephyr.conf
kernel="zephyr.bin"
name="zephyr"
vcpus=1
memory=16
gic_version="v2"
on_crash="preserve"

qemu-aarch64 ~ #  xl create -c zephyr.conf
Parsing config from zephyr.conf
libxl: info: libxl_create.c:122:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
(XEN) d3v0 Decoding instruction 0xa9bf7bfd is not supported
(XEN) d3v0 unhandled Arm instruction 0xa9bf7bfd
(XEN) d3v0 Unable to decode instruction

0xa9bf7bfd is:

a9bf7bfd        stp     x29, x30, [sp, #-16]!

mengtanhzc · 2024-10-11T08:47:15Z

@mengtanhzc I have suggestions, that your issue is caused by old bug in qemu timer handling. We had this problem also with Zephyr Dom0 and tried to upstream a patch, but maintainers prepared their own and added it in mainline.
You can check this and verify if your Qemu version contains it - https://patchew.org/QEMU/[email protected]/

Hello. Have you encountered the following problem?

I modified the RAM area of Zephyr:
$ git diff .
diff --git a/boards/xen/xenvm/xenvm.dts b/boards/xen/xenvm/xenvm.dts
index bbba268d9a3..eb477b8bc2b 100644
--- a/boards/xen/xenvm/xenvm.dts
+++ b/boards/xen/xenvm/xenvm.dts
@@ -46,9 +46,9 @@
                method = "hvc";
        };

-       ram: memory@40000000 {
+       ram: memory@70000000 {
                device_type = "mmio-sram";
-               reg = <0x00 0x40000000 0x00 DT_SIZE_M(16)>;
+               reg = <0x00 0x70000000 0x00 DT_SIZE_M(16)>;
        };

        gic: interrupt-controller@3001000 {
and now I get an error when I run it.
qemu-aarch64 ~ # cat zephyr.conf
kernel="zephyr.bin"
name="zephyr"
vcpus=1
memory=16
gic_version="v2"
on_crash="preserve"

qemu-aarch64 ~ #  xl create -c zephyr.conf
Parsing config from zephyr.conf
libxl: info: libxl_create.c:122:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
(XEN) d3v0 Decoding instruction 0xa9bf7bfd is not supported
(XEN) d3v0 unhandled Arm instruction 0xa9bf7bfd
(XEN) d3v0 Unable to decode instruction
0xa9bf7bfd is:
a9bf7bfd        stp     x29, x30, [sp, #-16]!

I made a mistake that has led to these bugs...

The memory layout should be modified based on the DTB by using LIBXL_DEBUG_DUMP_DTB, and the system clock frequency should be modified.
The current memory layout of the zephyr samples is fine. I just need to modify the clock frequency and upgrade the qemu version.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How do I get zephyr-domU working with xen? #42

How do I get zephyr-domU working with xen? #42

mengtanhzc commented Sep 10, 2024 •

edited

Loading

GrygiriiS commented Sep 10, 2024

firscity commented Sep 10, 2024

mengtanhzc commented Sep 10, 2024

mengtanhzc commented Sep 10, 2024

mengtanhzc commented Sep 11, 2024

GrygiriiS commented Sep 11, 2024

mengtanhzc commented Oct 8, 2024 •

edited

Loading

mengtanhzc commented Oct 8, 2024 •

edited

Loading

mengtanhzc commented Oct 11, 2024

How do I get zephyr-domU working with xen? #42

How do I get zephyr-domU working with xen? #42

Comments

mengtanhzc commented Sep 10, 2024 • edited Loading

GrygiriiS commented Sep 10, 2024

firscity commented Sep 10, 2024

mengtanhzc commented Sep 10, 2024

mengtanhzc commented Sep 10, 2024

mengtanhzc commented Sep 11, 2024

GrygiriiS commented Sep 11, 2024

mengtanhzc commented Oct 8, 2024 • edited Loading

mengtanhzc commented Oct 8, 2024 • edited Loading

mengtanhzc commented Oct 11, 2024

mengtanhzc commented Sep 10, 2024 •

edited

Loading

mengtanhzc commented Oct 8, 2024 •

edited

Loading

mengtanhzc commented Oct 8, 2024 •

edited

Loading