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. -- Best regards, Dmitry
