I'm unable to run a fully ARM64 virtualized rootfs image with QEMU after updating OP-TEE OS to 3.5, which seems to be causing virtio (block) related issues.
QEMU starts fine, booting Linux (5.0-based) up to the point where it tries to mount the rootfs and start the main system, at which point it just freezes completely. This same setup and same image works fine when using OP-TEE 3.4, but not with 3.5+.
The error message I see on the QEMU side when booting the system:
$ qemu-system-aarch64 -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 \
-netdev user,id=net0,hostfwd=tcp::2222-:22 \
-drive if=virtio,file=lmp-gateway-image-qemuarm64.wic,format=raw \
-no-reboot -no-acpi -bios bl1.bin -d unimp -semihosting-config enable,target=native \
-nographic -machine virt,secure=on -cpu cortex-a57 -m 1057 -smp 2 -S \
-serial telnet:127.0.0.1:4444,server,nowait -serial telnet:127.0.0.1:4445,server,nowait
QEMU 4.0.0 monitor - type 'help' for more information
(qemu) c
(qemu) qemu-system-aarch64: virtio: bogus descriptor or out of resources
Bisecting OP-TEE OS after 3.4 got me to commit e9495e2, and I can confirm that even current HEAD works fine after reverting this change.
Looks like the dt reserve for tzdram is somehow confusing the kernel/qemu, only thing I'm not yet sure is why this is happening, since the tzdram offset seems correct:
out/arm/include/generated/conf.h:#define CFG_TZDRAM_SIZE 0x00f00000
out/arm/include/generated/conf.h:#define CFG_TZDRAM_START 0x0e100000
And from QEMU: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L140
The only thing I noticed is that there is no need to reserve that region with QEMU as it is already set and initialized via https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L1300
Not sure if a conflict from qemu/linux side yet, but wanted to report the issue in case anyone is also able to reproduce it.
I'm unable to run a fully ARM64 virtualized rootfs image with QEMU after updating OP-TEE OS to 3.5, which seems to be causing virtio (block) related issues.
QEMU starts fine, booting Linux (5.0-based) up to the point where it tries to mount the rootfs and start the main system, at which point it just freezes completely. This same setup and same image works fine when using OP-TEE 3.4, but not with 3.5+.
The error message I see on the QEMU side when booting the system:
Bisecting OP-TEE OS after 3.4 got me to commit e9495e2, and I can confirm that even current HEAD works fine after reverting this change.
Looks like the dt reserve for tzdram is somehow confusing the kernel/qemu, only thing I'm not yet sure is why this is happening, since the tzdram offset seems correct:
And from QEMU: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L140
The only thing I noticed is that there is no need to reserve that region with QEMU as it is already set and initialized via https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L1300
Not sure if a conflict from qemu/linux side yet, but wanted to report the issue in case anyone is also able to reproduce it.