From: Vivek Kasireddy <vivek.kasireddy@intel.com>
To: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: "Vivek Kasireddy" <vivek.kasireddy@intel.com>,
"Michal Wajdeczko" <michal.wajdeczko@intel.com>,
"Michał Winiarski" <michal.winiarski@intel.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Matthew Auld" <matthew.auld@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Dongwon Kim" <dongwon.kim@intel.com>
Subject: [PATCH v2 0/5] drm/xe/sriov: Don't migrate dmabuf BO to System RAM while running in VM
Date: Sun, 20 Oct 2024 22:21:28 -0700 [thread overview]
Message-ID: <20241021052236.1820329-1-vivek.kasireddy@intel.com> (raw)
While testing [1] and [2] with a SRIOV enabled dGPU, it was noticed
that migrating a BO to System RAM before exporting it as a dmabuf
results in considerable performance degradation while running in a
Guest VM. For example, running a simple 3D app such as weston-simple-egl
would yield ~50 FPS instead of ~59 FPS, assuming a mode of 1920x1080@60.
One fix to this problem is to not migrate the BO and keep it in LMEM
during export. However, given that the GPU running in PF mode on the
Host cannot effectively access the PCI BAR addresses backing the
imported dmabuf BO, they need to be translated into LMEM addresses
(DPA) to enable this use-case to work properly.
With this patch series applied, it would become possible to display
(via Qemu GTK UI) Guest VM compositor's framebuffer (created in its LMEM)
on the Host without having to make any copies of it or a roundtrip
to System RAM. And, weston-simple-egl can now achieve ~59 FPS while
running with Gnome Wayland in the Guest VM.
Changelog:
v1 -> v2:
- Use a dma_addr array instead of SG table to store translated DMA
addresses (Matt)
- Use a cursor to iterate over the entries in the dma_addr array
instead of relying on SG iterator (Matt)
- Rebased and tested this series on top of [3] that introduces
drm_pagemap_dma_addr and xe_res_first_dma/__xe_res_dma_next
that this version relies on
[1] https://patchwork.freedesktop.org/series/131746/
[2] https://patchwork.freedesktop.org/series/135273/
[3] https://patchwork.freedesktop.org/series/137870/
Patchset overview:
Patch 1: PCI driver patch to unblock P2P DMA between VF and PF
Patch 2: Prevent BO migration to System RAM while running in VM
Patch 3: Helper function to get VF's backing object in LMEM
Patch 4-5: Create a new dma_addr array for LMEM based dmabuf BOs
to store translated addresses (DPAs)
This series is tested using the following method:
- Run Qemu with the following relevant options:
qemu-system-x86_64 -m 4096m ....
-device vfio-pci,host=0000:03:00.1
-device virtio-vga,max_outputs=1,blob=true,xres=1920,yres=1080
-display gtk,gl=on
-object memory-backend-memfd,id=mem1,size=4096M
-machine memory-backend=mem1 ...
- Run Gnome Wayland with the following options in the Guest VM:
# cat /usr/lib/udev/rules.d/61-mutter-primary-gpu.rules
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary", TAG+="mutter-device-disable-kms-modifiers"
# XDG_SESSION_TYPE=wayland dbus-run-session -- /usr/bin/gnome-shell --wayland --no-x11 &
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Vivek Kasireddy (5):
PCI/P2PDMA: Don't enforce ACS check for functions of same device
drm/xe/dmabuf: Don't migrate BO to System RAM while running in VF mode
drm/xe/pf: Add a helper function to get a VF's backing object in LMEM
drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with
VFs
drm/xe/pt: Add an additional check for dmabuf BOs while updating PTEs
drivers/gpu/drm/xe/xe_bo.c | 116 +++++++++++++++++++--
drivers/gpu/drm/xe/xe_bo_types.h | 11 +-
drivers/gpu/drm/xe/xe_dma_buf.c | 9 +-
drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 23 ++++
drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h | 1 +
drivers/gpu/drm/xe/xe_pt.c | 8 +-
drivers/pci/p2pdma.c | 17 ++-
7 files changed, 172 insertions(+), 13 deletions(-)
--
2.45.1
next reply other threads:[~2024-10-21 5:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 5:21 Vivek Kasireddy [this message]
2024-10-21 5:21 ` [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for functions of same device Vivek Kasireddy
2024-10-22 15:16 ` Bjorn Helgaas
2024-10-22 21:15 ` Logan Gunthorpe
2024-10-24 5:50 ` Kasireddy, Vivek
2024-10-24 16:21 ` Logan Gunthorpe
2024-10-24 18:01 ` Bjorn Helgaas
2024-10-24 5:58 ` Kasireddy, Vivek
2024-10-24 17:59 ` Bjorn Helgaas
2024-10-25 6:57 ` Kasireddy, Vivek
2024-10-30 18:46 ` Bjorn Helgaas
2024-10-30 21:20 ` Logan Gunthorpe
2024-10-30 22:07 ` Bjorn Helgaas
2024-10-31 6:59 ` Kasireddy, Vivek
2024-10-21 5:21 ` [PATCH v2 2/5] drm/xe/dmabuf: Don't migrate BO to System RAM while running in VF mode Vivek Kasireddy
2024-10-21 5:21 ` [PATCH v2 3/5] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM Vivek Kasireddy
2024-10-21 5:21 ` [PATCH v2 4/5] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs Vivek Kasireddy
2024-10-22 10:12 ` kernel test robot
2024-10-22 10:54 ` kernel test robot
2024-10-21 5:21 ` [PATCH v2 5/5] drm/xe/pt: Add an additional check for dmabuf BOs while updating PTEs Vivek Kasireddy
2024-10-22 12:58 ` kernel test robot
2024-10-21 5:52 ` ✓ CI.Patch_applied: success for drm/xe/sriov: Don't migrate dmabuf BO to System RAM while running in VM (rev2) Patchwork
2024-10-21 5:52 ` ✗ CI.checkpatch: warning " Patchwork
2024-10-21 5:52 ` ✗ CI.KUnit: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241021052236.1820329-1-vivek.kasireddy@intel.com \
--to=vivek.kasireddy@intel.com \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=michal.winiarski@intel.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox