[PATCH v2 2/5] drm/virtio: Add a helper to map and note the dma addrs and lengths

[Kasireddy, Vivek]

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
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