Redroid does not work with a virtio host GPU when docker is within the full system emulator qemu-system-aarch64 #705
Comments
Inside of redroid-debug.oXCPXh9W.tgz |
|
I made a further observation, while watching
|
|
And finally, the reason why userspace emulation isn't sufficient is because it doesn't work on certain specific apps. One example is Termux. The aarch64 build of Termux does not work within amd64 redroid that has a userspace ARM emulator, so, the ultimate goal here is run the aarch64 build of Termux on amd64 hardware |
|
Actually, it really was just loading! This time, I waited for 7 hours and it finally progressed past that part and booted fully, now I am able to connect with However it would be really nice to be able to have similar GPU performance to everything else, by getting surfaceflinger to utilize the same virtio GPU that the Arch Linux ARM Xorg is able to. But, unfortunately that might be very difficult, because I see this in the output from qemu-system-aarch64 output when trying to connect surfaceflinger to the virtio GPUAlso, if Xorg is running in the KMS+DRM viewport (the QEMU SDL window) when I try to launch redroid with host gpu mode, Xorg freezes. I guess this might indicate it is a bug with QEMU or the virtio driver itself. Here is a copy of everything from the After the 7 hours have passed, kernel log messages begin printing quickly again and redroid becomes possible to connect to using In gpu guest mode, it is now working pretty good after I wait the time for it to boot, so I will use that for now. |
robertkirkman
changed the title
|
To summarize:
|
|
Well, the full system emulation is strongly not recommended (painfully slow w/ compatibility issues). How about native bridge (redroid already bundle this since redroid11)? Try a |
|
I will post a screenshot of the result I achieved that is the reason why I use this. When I tried the native bridge redroid, it was unable to reproduce this screenshot. The full system emulator causes this to work though.
|
|
Why not just use BTW, I believe the full system emulation is painfully slow, but should not that slow (you wait about 7 hours to boot redroid?). Again, strongly recommend native |
|
Yeah, actually you're right, I think I will figure out a different way because this way is too slow. |
|
GitHub Actions Arm Runner github/roadmap#955 might help me when it is available |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I have tried a lot of things to try to get the aarch64 redroid to run within
qemu-system-aarch64that is running on an amd64 hardware host, and trying to customize the distro runningdockerwithin QEMU until it is able to run redroid, but I haven't ever been successful. EDIT: I was successful today after trying again, so now it only has some problems like host GPU mode not workingIf this isn't a supported use-case that is ok. I just feel that someday, it will work, because my specific
qemu-system-aarch64instance has stronger performance than average due to the host having strong hardware, Ryzen 9 5950X and Radeon RX 5700 XT, which are utilized by the-smp 32and-device virtio-gpu-gl-pciarguments toqemu-system-aarch64:QEMU invocation
qemu-system-aarch64 -M virt \ -m 16384 \ -cpu cortex-a72 \ -smp 32 \ -drive if=pflash,media=disk,format=raw,cache=writethrough,file=flash0.img \ -drive if=pflash,media=disk,format=raw,cache=writethrough,file=flash1.img \ -drive if=none,file=archarmvm.qcow2,format=qcow2,id=hd0 \ -device virtio-scsi-pci,id=scsi0 \ -device scsi-hd,bus=scsi0.0,drive=hd0,bootindex=1 \ -nic user,model=virtio-net-pci,hostfwd=tcp::2222-:22 \ -device virtio-rng-device \ -device virtio-balloon-device \ -device virtio-serial-device \ -device virtio-tablet-device \ -object cryptodev-backend-builtin,id=cryptodev0 \ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ -device virtio-gpu-gl-pci,xres=1920,yres=1080 \ -display sdl,gl=on,show-cursor=on \ -device qemu-xhci,id=xhci \ -device usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/003/008 \ -device usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/003/009The way the
dockerservice runner, Arch Linux ARM, is installed withinqemu-system-aarch64is documented here. It is capable of running many aarch64 GNU/Linux apps with usable framerate, and is also capable of running other docker containers besides redroid. That is why I hope that performance might be sufficient to run redroid.I enabled the necessary kernel flags within the QEMU guest like this:
Arch Linux ARM custom kernel steps
Then I am trying to run redroid like this:
sudo docker run -itd --privileged -v ~/redroid-data:/data -p 5555:5555 -p 8022:8022 --name redroid redroid/redroid:14.0.0_64only-latest androidboot.use_memfd=trueThen
adb connect localhostandadb devices -lshowsoffline.make sure the required kernel modules present
grep binder /proc/filesystemsgrep ashmem /proc/misc(optional)Collect debug logs
curl -fsSL https://raw.githubusercontent.com/remote-android/redroid-doc/master/debug.sh | sudo bash -s -- redroidSee comment, and kernel config omitted because it is too big. My kernel config is this but with the patch described above applied.
Screenshots
If applicable, add screenshots to help explain your problem.
Single-thread performance gets 0.26 in this benchmark, which is comparable to the score of an older smartphone (Samsung Galaxy S III Sprint SPH-L710) - usable, and not frozen.
For this reason, I hope my QEMU has sufficient performance to run redroid, and the problem must be caused by a small detail somewhere, which can hopefully be solved.
The text was updated successfully, but these errors were encountered: