Hi Dmitry,
> > Subject: Re: [PATCH v2 2/5] drm/virtio: Add a helper to map and note the
> > dma addrs and lengths
> >
> > On 10/29/24 09:18, Kasireddy, Vivek wrote:
> > >>>> BTW, is any DG2 GPU suitable for testing of this patchset? Will I be
> > >>>> able to test it using a regular consumer A750 card?
> > >>> Yes, you can test with any DG2 dGPU as long as you can passthrough it
> to
> > >> the
> > >>> Guest VM. And, if there is an iGPU available on the Host, you can use
> > >> GTK/SDL UI
> > >>> for local display or Spice UI for remote display if there is no iGPU on the
> > >> Host.
> > >>> This is exactly how I started testing this patch series but I am now
> > >> predominantly
> > >>> testing this series with SRIOV enabled iGPUs and dGPUs.
> > >> Was hoping to try out SR-IOV on A750 if it's even possible at all.
> > > AFAIK, SRIOV is not supported on any versions of DG2 including A750.
> >
> > I'm having trouble with getting it to work.
> >
> > My testing setup:
> >
> > 1. Passthroughed A750 that uses XE driver
> I tested successfully with both i915 and Xe but DG2 is officially supported
> only with i915. Xe officially supports LNL and newer platforms. For older
> platforms,
> Mesa throws the following warning:
> MESA: warning: Support for this platform is experimental with Xe KMD, bug
> reports may be ignored.
>
> > 2. RaptorLake iGPU on host used for virtio-gpu, uses i915 driver
> I am testing with a similar setup: RPL-P iGPU + DG2
>
> > 3. QEMU latest master branch + your QEMU vfio_dmabuf_2 patches
> applied
> > on top
> I just tried with latest Qemu master and it appears to be very sluggish in my
Turns out, the sluggishness is the result of a busy loop triggered by this patch in Qemu:
commit 640f9149c3dcafbfeb495a10f6105c6f71f24d1d
Author: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx>
Date: Fri Oct 25 00:03:08 2024 +0300
virtio-gpu: Support suspension of commands processing
Check whether command processing has been finished; otherwise, stop
processing commands and retry the command again next time. This allows
us to support asynchronous execution of non-fenced commands needed for
unmapping host blobs safely.
The above patch exposes an issue that occurs in very specific cases that
make use of single FB (such as fbcon and dirtyfb) where a fence is not added
to the (resource_flush) cmd. However, this issue can be fixed in the Guest
virtio drm driver by including the following patch:
commit cef51cbd7ac70d225eaa0d4d47e6e29f66ebcedf
Author: Dongwon Kim <dongwon.kim@xxxxxxxxx>
Date: Mon Oct 21 02:08:03 2024 +0300
drm/virtio: New fence for every plane update
Having a fence linked to a virtio_gpu_framebuffer in the plane update
sequence would cause conflict when several planes referencing the same
framebuffer (e.g. Xorg screen covering multi-displays configured for an
extended mode) and those planes are updated concurrently. So it is needed
to allocate a fence for every plane state instead of the framebuffer.
After rebasing v2 of this patch series on top of the above patch, I see that
this use-case works as expected with Qemu master. Let me send out v3,
which would be a rebase of v2 on top of the above patch.
Thanks,
Vivek
> environment (Fedora 39 Guest and Fedora 39 Host). But, few months old
> Qemu master + vfio_dmabuf_2 patches (actually, these patches are not
> needed
> to test this patch series with GTK/SDL) seems to work OK for me. And, here
> are
> the relevant Qemu launch options I am using:
> qemu-system-x86_64 -m 4096m -enable-kvm -cpu host,host-phys-
> bits=on,host-phys-bits-limit=39....
> -device vfio-pci,host=0000:03:00.0 -device virtio-
> vga,max_outputs=1,xres=1920,yres=1080,blob=true
> -display gtk,gl=on -object memory-backend-memfd,id=mem1,size=4096M -
> machine memory-backend=mem1.......
>
> > 4. Latest linux-next kernel on host
> > 5. Latest linux-next kernel on guest + this v2 applied
> I just tested successfully with today's drm-tip (6.12) + v2 of this series.
>
> >
> > In guest I'm running this:
> >
> > seatd-launch -- weston --drm-device=card1 --additional-devices=card0
> >
> > where card1 is A750 and card0 is virtio-gpu.
> >
> > I added printk's and see that virtio-gpu imports A750 dma-buf and gets
> > XE's SGT, but nothing shows on the QEMU display.
> Could you please try this test again with i915 instead of Xe? Also, are there
> any errors seen in Guest or Host logs?
>
> > I tried both GTK and SPICE displays.
> GTK should be simpler given that there are other components (Gstreamer,
> etc)
> needed for SPICE that have their own set of dependencies.
>
> > If I connect HDMI display to passthroughed A750 while
> > running weston command above, then I get weston working on the A750
> > HDMI
> > display and still nothing is shown on virtio-gpu display.
> I tried this exact same test and it seems to work OK for me. Could you please
> also test
> Gnome + Wayland:
> XDG_SESSION_TYPE=wayland dbus-run-session -- /usr/bin/gnome-shell --
> wayland --no-x11 &
>
> Note that, for Weston, the primary device (drm-device=) needs to support
> KMS and
> have at-least one connector connected. For Gnome + Wayland, there is no
> such
> requirement as the primary device can work with dummy backend and be
> used
> only for rendering. Therefore, to test Gnome with DG2 in Guest, I typically do
> modprobe i915 enable_guc=3 disable_display=true
>
> >
> > I also had to force virtio-gpu driver to always probe before XE,
> > otherwise virtio-gpu gets PCI read errors and fails to probe because it
> > fails to detect virtio features.
> That is concerning. I guess we'll need to investigate how to fix this properly.
> As part of my tests, I typically blacklist Xe and i915 and load them later
> after booting to the cmd line and before launching the compositors.
>
> >
> > Am I doing anything wrong? Suggestions are welcome.
> Could you please share your Qemu launch parameters? I'll try to recreate the
> issue you are seeing.
>
> Thanks,
> Vivek
>
> >
> > --
> > Best regards,
> > Dmitry
