Re: [PATCH v4 0/5] Support virtio-gpu DRM native context

["Alex Bennée" <alex.bennee@linaro.org>]

Alex Bennée <alex.bennee@linaro.org> writes:

> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>
>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>
>> Contarary to Virgl and Venus contexts which mediate high level GFX APIs,
>> DRM native context [1] mediates lower level kernel driver UAPI, which
>> reflects in a less CPU overhead and less/simpler code needed to support it.
>> DRM context consists of a host and guest parts that have to be implemented
>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
>> a real/native host GPU device for GL/VK applications.
>>
>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ
>>
>> Today there are four known DRM native context drivers existing in a wild:
>>
>>   - Freedreno (Qualcomm SoC GPUs), completely upstreamed
>>   - AMDGPU, mostly merged into upstreams
>>   - Intel (i915), merge requests are opened
>>   - Asahi (Apple SoC GPUs), WIP status
>>
>>
>> # How to try out DRM context:
>>
>> 1. DRM context uses host blobs and requires latest developer version 
>> of Linux kernel [2] that has necessary KVM fixes.
>>
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
>>
>> 2. Use latest libvirglrenderer from upstream git/main for Freedreno
>> and AMDGPU native contexts. For Intel use patches [3].
>>
>> [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
>>
>> 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use
>> Mesa patches [4], for Intel [5].
>>
>> [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658
>> [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
>>
>> 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're
>>    running Xorg in guest.
>
> Have you seen this failure before:
>
>   ➜  ./qemu-system-x86_64 \
>                     -machine type=q35,accel=kvm,kernel-irqchip=split \
>                     -cpu host \
>                     -smp 4 \
>                     -device virtio-net-pci,netdev=unet \
>                     -netdev user,id=unet,hostfwd=tcp::2222-:22 \
>                     -drive driver=qcow2,file=trixie-x86_64.qcow2 \
>                     -serial mon:stdio \
>                     -m 24G \
>                     -object memory-backend-memfd,id=mem,size=24G,share=on \
>                     -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \
>                     -display gtk,gl=on,show-cursor=on \
>                     -device virtio-tablet-pci -device virtio-keyboard-pci \
>                     -d guest_errors,unimp,trace:virtio_gpu_cmd_get_display_info
>   vmport: unknown command 56
>   virtio_gpu_cmd_get_display_info 
>   context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22
>   vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735
>   context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22
>   vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735
>   context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22
>   vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735
>   error: kvm run failed Bad address
>   RAX=00007fb1e8fbefa0 RBX=00005649f1f4fb34 RCX=00000000fffffffc RDX=0000000000000004
>   RSI=0000000000000000 RDI=0000000000100000 RBP=00005649f2063710 RSP=00007ffe221807d0
>   R8 =0000000000000003 R9 =00007ffe22180808 R10=0000000000000302 R11=0000000000000000
>   R12=0000000000000001 R13=00007ffe22180800 R14=0000000000000002 R15=0000000000000001
>   RIP=00007fb20bfc3f7f RFL=00010202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
>   ES =0000 0000000000000000 ffffffff 00c00000
>   CS =0033 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA]
>   SS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
>   DS =0000 0000000000000000 ffffffff 00c00000
>   FS =0000 00007fb203aace80 ffffffff 00c00000
>   GS =0000 0000000000000000 ffffffff 00c00000
>   LDT=0000 0000000000000000 ffffffff 00c00000
>   TR =0040 fffffe67eec85000 00004087 00008b00 DPL=0 TSS64-busy
>   GDT=     fffffe67eec83000 0000007f
>   IDT=     fffffe0000000000 00000fff
>   CR0=80050033 CR2=00005646b7f7d018 CR3=000000012852a000 CR4=00750ef0
>   DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
>   DR6=00000000ffff0ff0 DR7=0000000000000400
>   EFER=0000000000000d01
>   Code=f3 0f 11 40 58 f3 0f 10 43 08 f3 0f 11 40 5c f3 0f 10 43 0c <f3> 0f 11 78 64 f3 0f 11 50 68 f3 44 0f 11 40 6c f3 0f 11 48 70 f3 0f 11 60 74 f3 0f 11 40

So this goes away with:

  Linux draig 6.13.0-rc6-ajb-00144-g8c8d54116fa2-dirty #27 SMP PREEMPT_DYNAMIC Fri Jan 10 16:57:29 GMT 2025 x86_64 GNU/Linux

So I think is an artefact of the PFN page locking failing. I guess
native context is more prone to issues? It is a bit odd as I have loads
of memory and I think the intel graphics are unified memory but I don't
know how you would check.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro