Hi Dmitry, The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine. I'm not sure if anyone has successfully run it on an ARM64 machine before.
When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14. Here are the commands and error messages I encountered: ``` phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0 phytium@ubuntu:~/working/virglrenderer$ phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0 error: kvm run failed Bad address PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00 X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14 X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8 X08=00000000000000de X09=0000000000000200 X10=0000000000001000 X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001 X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0 X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060 X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000 X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0 X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0 X29=0000e2bc9e46c610 X30=0000e2bcac809c38 SP=0000e2bc9e46c510 PSTATE=20001000 --C- EL0t phytium@ubuntu:~/working/virglrenderer$ uname -a Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr 7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux ``` Best regards, Cong > -----Original Messages----- > From: "Dmitry Osipenko" <dmitry.osipe...@collabora.com> > Send time:Sunday, 04/27/2025 06:27:39 > To: 刘聪 <liucong2...@phytium.com.cn> > Cc: jiqian.c...@amd.com, akihiko.od...@daynix.com, alex.ben...@linaro.org, > alexander.deuc...@amd.com, christian.koe...@amd.com, > gert.wol...@collabora.com, gurchetansi...@chromium.org, h...@alyssa.is, > honglei1.hu...@amd.com, julia.zh...@amd.com, kra...@redhat.com, > marcandre.lur...@redhat.com, m...@redhat.com, pbonz...@redhat.com, > phi...@linaro.org, pierre-eric.pelloux-pra...@amd.com, qemu-devel@nongnu.org, > ray.hu...@amd.com, robdcl...@gmail.com, roger....@citrix.com, > s...@redhat.com, stefano.stabell...@amd.com, xenia.ragiada...@amd.com, > zzyi...@chromium.org > Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing > > On 4/14/25 17:47, Dmitry Osipenko wrote: > > On 4/11/25 04:42, 刘聪 wrote: > >> > >> > >> > >>> -----Original Messages----- > >>> From: "Dmitry Osipenko" <dmitry.osipe...@collabora.com> > >>> Send time:Friday, 04/11/2025 05:59:11 > >>> To: "Cong Liu" <liucong2...@phytium.com.cn> > >>> Cc: jiqian.c...@amd.com, akihiko.od...@daynix.com, > >>> alex.ben...@linaro.org, alexander.deuc...@amd.com, > >>> christian.koe...@amd.com, gert.wol...@collabora.com, > >>> gurchetansi...@chromium.org, h...@alyssa.is, honglei1.hu...@amd.com, > >>> julia.zh...@amd.com, kra...@redhat.com, marcandre.lur...@redhat.com, > >>> m...@redhat.com, pbonz...@redhat.com, phi...@linaro.org, > >>> pierre-eric.pelloux-pra...@amd.com, qemu-devel@nongnu.org, > >>> ray.hu...@amd.com, robdcl...@gmail.com, roger....@citrix.com, > >>> s...@redhat.com, stefano.stabell...@amd.com, xenia.ragiada...@amd.com, > >>> zzyi...@chromium.org > >>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing > >>> > >>> 10.04.2025 12:54, Cong Liu пишет: > >>>> I discovered that on an ARM64 environment, the 'virtio-gpu: Support > >>>> asynchronous fencing' patch causes the virtual machine GUI to fail to > >>>> display. Rolling back this patch and using virgl allows the virtual > >>>> machine to start normally. When the VM screen is black, I can see some > >>>> errors in QEMU. I used QEMU's -serial stdio to enter the virtual > >>>> machine's command line console but didn't see any errors inside the VM - > >>>> the graphical interface seems to be stuck. I would greatly appreciate > >>>> any suggestions regarding effective troubleshooting methods or specific > >>>> areas I should investigate to resolve this issue. > >>>> > >>>> Here's my software and hardware environment: > >>>> - host and guest are ubuntu 24.04 > >>>> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git > >>>> native-context-v11 branch > >>>> - virglrender: latest main branch > >>>> 08eb12d00711370002e8f8fa6d620df9b79f9e27 > >>>> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 > >>>> noble-oibaf-ppa) > >>>> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048 > >>>> - GPU: Radeon RX 6600/6600 XT/6600M > >>>> - CPU: phytium D3000 aarch64 > >>>> > >>>> Here's the command I'm using to run the virtual machine, which displays > >>>> a black frame with "Display output is not active" and fails to start the > >>>> graphical interface normally: > >>>> > >>>> phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 > >>>> --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive > >>>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio > >>>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device > >>>> virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display > >>>> gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device > >>>> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0 > >>>> > >>>> (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed > >>>> (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed > >>>> (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed > >>>> (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed > >>>> (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed > >>>> > >>>> When using SDL, the error messages are slightly different: > >>>> > >>>> phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 > >>>> --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive > >>>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio > >>>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device > >>>> virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display > >>>> sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device > >>>> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0 > >>>> > >>>> vrend_renderer_fill_caps: Entering with stale GL error: 1286 > >>>> > >>> > >>> Hi, > >>> > >>> 1. Please make sure that you're not only building QEMU against your > >>> virglrenderer version, but also setting LD_LIBRARY_PATH properly at > >>> runtime. Best to remove system version of virglrenderer if unsure, > >> > >> I built and installed virglrenderer with the --prefix=/usr option, so > >> it replaces the system version as expected. > >> > >>> > >>> 2. Can you reproduce this problem using tcg instead of kvm? > >>> > >> > >> yes, change qemu command '--machine virt,accel=kvm -cpu host' to > >> '--machine virt -cpu max' can reproduce this problem. > >>> -- > >>> Best regards, > >>> Dmitry > >> > >> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c > >> index f6df9dcb..f6e06842 100644 > >> --- a/src/vrend_renderer.c > >> +++ b/src/vrend_renderer.c > >> @@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, > >> uint32_t version, > >> union virgl_caps *caps) > >> { > >> int gl_ver, gles_ver; > >> - GLenum err; > >> + GLenum err = GL_NO_ERROR; > >> bool fill_capset2 = false; > >> > >> if (!caps) > >> > >> phytium@d3000:~/working/qemu$ git log --oneline -n 10 > >> e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert > >> "amd_iommu: Add support for pass though mode" > >> d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements > >> 55db821ea5 docs/system: virtio-gpu: Update Venus link > >> 003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc > >> 7674e82755 ui/gtk: Don't disable scanout when display is refreshed > >> 712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed > >> 9003da356f virtio-gpu: Support DRM native context > >> e2ff4f4a48 virtio-gpu: Support asynchronous fencing > >> 25458c7625 virtio-gpu: Handle virgl fence creation errors > >> > >> I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, > >> but it doesn’t seem to resolve the “Entering with stale GL error: 1286” > >> message. However, this error might not be directly related to the VM black > >> screen issue. I noticed that even when the VM was working > >> correctly—specifically when I reset to commit 25458c7625—the same GL error > >> still appeared. > > > > Thanks for the report. I confirm that something is wrong with virgl when > > async fencing is used. Don't have this GL 1286 error, but getting a > > lockup on ARM VM and with one of my new x64 VM setups. Will investigate > > further and report back here. > > Hi, Cong. Please give a test to [1]. It fixes the problem for me. > > [1] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1518 > > -- > Best regards, > Dmitry 信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。 Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
