[PATCH v4 0/5] drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[PATCH v4 0/5] drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[Vivek Kasireddy]

While running 3D apps inside a Guest VM 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.
For example, running a simple 3D app such as weston-simple-egl
would yield ~44 FPS instead of ~59 FPS, assuming a mode of
1920x1080@60.

So, fix this issue by not migrating the BO and keep it in LMEM
during export if the P2P test (pci_p2pdma_distance()) succeeds.
However, since 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 (DPAs)
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
costly roundtrip to System RAM. And, weston-simple-egl can now
achieve ~59 FPS while running with Gnome Wayland in the Guest VM.

Changelog:
v3 -> v4:
- Drop the IS_SRIOV_VF() check in xe_dma_buf_pin() and instead rely
  on Qemu's virtual PCI ports to make virtio-gpu P2P compatible
  with VF
- Add an additional condition to check for Intel GPU in P2PDMA patch
  (Logan)
- Ensure that a reference is taken on VF's backing object in LMEM
  (Michal)
- Create a new type to store dma data for external dmabuf BOs

v2 -> v3:
- Rebased (and tested) on kernel 6.17.0-rc4 with B60
- Updated the commit message in the P2PDMA patch and other patches

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 the one that introduces
  drm_pagemap_dma_addr and xe_res_first_dma/__xe_res_dma_next
  that this version relies on

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 and use a new dma_addr array for LMEM based
           dmabuf BOs to store translated addresses (DPAs)

Associated Qemu patch series:
https://lore.kernel.org/qemu-devel/20250903054438.1179384-1-vivek.kasireddy@intel.com/
Associated vfio-pci patch series:
https://lore.kernel.org/linux-mm/cover.1754311439.git.leon@kernel.org/

This series is tested using the following method:
- Run Qemu with the following relevant options:
  qemu-system-x86_64 -m 4096m ....
  -device ioh3420,id=root_port1,bus=pcie.0
  -device x3130-upstream,id=upstream1,bus=root_port1
  -device xio3130-downstream,id=downstream1,bus=upstream1,chassis=9
  -device xio3130-downstream,id=downstream2,bus=upstream1,chassis=10
  -device vfio-pci,host=0000:03:00.1,bus=downstream1
  -device virtio-gpu,max_outputs=1,blob=true,xres=1920,yres=1080,bus=downstream2
  -display gtk,gl=on
  -object memory-backend-memfd,id=mem1,size=4096M
  -machine q35,accel=kvm,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: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>

Vivek Kasireddy (5):
  PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs
  drm/xe/dmabuf: Don't migrate BO to System RAM if P2P check succeeds
  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 doing bind

 drivers/gpu/drm/xe/xe_bo.c                 | 101 ++++++++++++++++++++-
 drivers/gpu/drm/xe/xe_bo_types.h           |  12 +++
 drivers/gpu/drm/xe/xe_dma_buf.c            |   5 +-
 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/gpu/drm/xe/xe_sriov_pf_types.h     |  19 ++++
 drivers/pci/p2pdma.c                       |  15 ++-
 8 files changed, 180 insertions(+), 4 deletions(-)

-- 
2.50.1

[PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Vivek Kasireddy]

Typically, functions of the same PCI device (such as a PF and a VF)
share the same bus and have a common root port and the PF provisions
resources for the VF. Given this model, they can be considered
compatible as far as P2PDMA access is considered.

Currently, although the distance (2) is correctly calculated for
functions of the same device, an ACS check failure prevents P2P DMA
access between them. Therefore, introduce a small function named
pci_devfns_support_p2pdma() to determine if the provider and client
belong to the same device and facilitate P2PDMA between them by
not enforcing the ACS check.

However, since it is hard to determine if the device functions of
any given PCI device are P2PDMA compatible, we only relax the ACS
check enforcement for device functions of Intel GPUs. This is
because the P2PDMA communication between the PF and VF of Intel
GPUs is handled internally and does not typically involve the PCIe
fabric.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: <linux-pci@vger.kernel.org>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
v1 -> v2:
- Relax the enforcment of ACS check only for Intel GPU functions
  as they are P2PDMA compatible given the way the PF provisions
  the resources among multiple VFs.

v2 -> v3:
- s/pci_devs_are_p2pdma_compatible/pci_devfns_support_p2pdma
- Improve the commit message to explain the reasoning behind
  relaxing the ACS check enforcement only for Intel GPU functions.

v3 -> v4: (Logan)
- Drop the dev_is_pf() hunk as no special handling is needed for PFs
- Besides the provider, also check to see the client is an Intel GPU
---
 drivers/pci/p2pdma.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index da5657a02007..0a1d884cd0ff 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -544,6 +544,19 @@ static unsigned long map_types_idx(struct pci_dev *client)
 	return (pci_domain_nr(client->bus) << 16) | pci_dev_id(client);
 }
 
+static bool pci_devfns_support_p2pdma(struct pci_dev *provider,
+				      struct pci_dev *client)
+{
+	if (provider->vendor == PCI_VENDOR_ID_INTEL &&
+	    client->vendor == PCI_VENDOR_ID_INTEL) {
+		if ((pci_is_vga(provider) && pci_is_vga(client)) ||
+		    (pci_is_display(provider) && pci_is_display(client)))
+			return pci_physfn(provider) == pci_physfn(client);
+	}
+
+	return false;
+}
+
 /*
  * Calculate the P2PDMA mapping type and distance between two PCI devices.
  *
@@ -643,7 +656,7 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
 
 	*dist = dist_a + dist_b;
 
-	if (!acs_cnt) {
+	if (!acs_cnt || pci_devfns_support_p2pdma(provider, client)) {
 		map_type = PCI_P2PDMA_MAP_BUS_ADDR;
 		goto done;
 	}
-- 
2.50.1

[PATCH v4 2/5] drm/xe/dmabuf: Don't migrate BO to System RAM if P2P check succeeds

[Vivek Kasireddy]

If the P2P test (i.e, pci_p2pdma_distance()) is successful, then it
means that the importer can directly access the BO located in VRAM.
Therefore, in this specific case, do not migrate the BO to System
RAM before exporting it.

Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 drivers/gpu/drm/xe/xe_dma_buf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
index a7d67725c3ee..04082e3e4295 100644
--- a/drivers/gpu/drm/xe/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/xe_dma_buf.c
@@ -52,7 +52,7 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
 	struct xe_bo *bo = gem_to_xe_bo(obj);
 	struct xe_device *xe = xe_bo_device(bo);
 	struct drm_exec *exec = XE_VALIDATION_UNSUPPORTED;
-	int ret;
+	int ret = 0;
 
 	/*
 	 * For now only support pinning in TT memory, for two reasons:
@@ -64,7 +64,8 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
 		return -EINVAL;
 	}
 
-	ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
+	if (!attach->peer2peer)
+		ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
 	if (ret) {
 		if (ret != -EINTR && ret != -ERESTARTSYS)
 			drm_dbg(&xe->drm,
-- 
2.50.1

[PATCH v4 3/5] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM

[Vivek Kasireddy]

To properly import a dmabuf that is associated with a VF (or that
originates in a Guest VM that includes a VF), we need to know where
in LMEM the VF's allocated regions exist. Therefore, introduce a
new helper to return the object that backs the VF's regions in LMEM.

v2:
- Make the helper return the LMEM object instead of the start address

v3:
- Move the declaration of the helper under other lmem helpers (Michal)

Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 23 ++++++++++++++++++++++
 drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
index 6344b5205c08..1bfcd35cc8ef 100644
--- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
+++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
@@ -1535,6 +1535,29 @@ u64 xe_gt_sriov_pf_config_get_lmem(struct xe_gt *gt, unsigned int vfid)
 	return size;
 }
 
+/**
+ * xe_gt_sriov_pf_config_get_lmem_obj - Get VF's LMEM BO.
+ * @gt: the &xe_gt
+ * @vfid: the VF identifier
+ *
+ * This function can only be called on PF.
+ *
+ * Return: BO that is backing VF's quota in LMEM.
+ */
+struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt,
+						 unsigned int vfid)
+{
+	struct xe_gt_sriov_config *config;
+	struct xe_bo *lmem_obj;
+
+	mutex_lock(xe_gt_sriov_pf_master_mutex(gt));
+	config = pf_pick_vf_config(gt, vfid);
+	lmem_obj = config->lmem_obj;
+	mutex_unlock(xe_gt_sriov_pf_master_mutex(gt));
+
+	return lmem_obj;
+}
+
 /**
  * xe_gt_sriov_pf_config_set_lmem - Provision VF with LMEM.
  * @gt: the &xe_gt (can't be media)
diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
index 513e6512a575..bbc5c238cbf6 100644
--- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
+++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
@@ -36,6 +36,7 @@ int xe_gt_sriov_pf_config_set_lmem(struct xe_gt *gt, unsigned int vfid, u64 size
 int xe_gt_sriov_pf_config_set_fair_lmem(struct xe_gt *gt, unsigned int vfid, unsigned int num_vfs);
 int xe_gt_sriov_pf_config_bulk_set_lmem(struct xe_gt *gt, unsigned int vfid, unsigned int num_vfs,
 					u64 size);
+struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt, unsigned int vfid);
 
 u32 xe_gt_sriov_pf_config_get_exec_quantum(struct xe_gt *gt, unsigned int vfid);
 int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid, u32 exec_quantum);
-- 
2.50.1

[PATCH v4 4/5] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs

[Vivek Kasireddy]

For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
associated with a VF, we need to adjust and translate these addresses
to LMEM addresses to make the BOs usable by the PF. Otherwise, the
BOs (i.e, PCI BAR addresses) are only accessible by the CPU and not
by the GPU.

In order to do the above, we first need to identify if the addresses
associated with an imported BO (type ttm_bo_type_sg) belong to System
RAM or a VF or other PCI devices. After we confirm that they belong to
a VF, we convert the BAR addresses to DPAs and create a new dma_addr
array (of type drm_pagemap_dma_addr) and populate it with the new
addresses along with the segment sizes.

v2:
- Use dma_addr array instead of sg table to store translated addresses
  (Matt)

v3:
- Remove the usage of iommu_iova_to_phys() as the imported BO would no
  longer contain IOVAs and would instead have BAR addresses.

v4:
- Take a reference on the VF's backing object in LMEM (Michal)
- Create a new type for storing dma data

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 drivers/gpu/drm/xe/xe_bo.c             | 101 ++++++++++++++++++++++++-
 drivers/gpu/drm/xe/xe_bo_types.h       |  12 +++
 drivers/gpu/drm/xe/xe_sriov_pf_types.h |  19 +++++
 3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index e6d16b34e5b5..a4e09fa88274 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -21,11 +21,13 @@
 
 #include <trace/events/gpu_mem.h>
 
+#include "regs/xe_bars.h"
 #include "xe_device.h"
 #include "xe_dma_buf.h"
 #include "xe_drm_client.h"
 #include "xe_ggtt.h"
 #include "xe_gt.h"
+#include "xe_gt_sriov_pf_config.h"
 #include "xe_map.h"
 #include "xe_migrate.h"
 #include "xe_pm.h"
@@ -33,6 +35,7 @@
 #include "xe_pxp.h"
 #include "xe_res_cursor.h"
 #include "xe_shrinker.h"
+#include "xe_sriov_pf_helpers.h"
 #include "xe_sriov_vf_ccs.h"
 #include "xe_trace_bo.h"
 #include "xe_ttm_stolen_mgr.h"
@@ -679,6 +682,90 @@ static int xe_bo_trigger_rebind(struct xe_device *xe, struct xe_bo *bo,
 	return ret;
 }
 
+static struct pci_dev *xe_find_vf_dev(struct xe_device *xe,
+				      phys_addr_t phys)
+{
+	struct pci_dev *pdev, *pf_pdev = to_pci_dev(xe->drm.dev);
+	resource_size_t io_start, io_size;
+
+	list_for_each_entry(pdev, &pf_pdev->bus->devices, bus_list) {
+		if (pdev->is_physfn)
+			continue;
+
+		io_start = pci_resource_start(pdev, LMEM_BAR);
+		io_size = pci_resource_len(pdev, LMEM_BAR);
+
+		if (phys >= io_start &&
+		    phys < (io_start + io_size - PAGE_SIZE))
+			return pdev;
+	}
+
+	return NULL;
+}
+
+
+static void xe_bo_translate_io_to_dpa(struct xe_bo *bo, struct sg_table *sg,
+				      resource_size_t io_start, int vfid)
+{
+	struct xe_device *xe = xe_bo_device(bo);
+	struct xe_gt *gt = xe_root_mmio_gt(xe);
+	struct scatterlist *sgl;
+	struct xe_bo *lmem_obj;
+	phys_addr_t phys;
+	dma_addr_t addr;
+	u64 offset, i;
+
+	lmem_obj = xe_gt_sriov_pf_config_get_lmem_obj(gt, ++vfid);
+	bo->dma_data.lmem_obj = xe_bo_get(lmem_obj);
+
+	for_each_sgtable_dma_sg(sg, sgl, i) {
+		phys = sg_dma_address(sgl);
+		offset = phys - io_start;
+		addr = xe_bo_addr(lmem_obj, offset, sg_dma_len(sgl));
+
+		bo->dma_data.dma_addr[i] = drm_pagemap_addr_encode(addr,
+						DRM_INTERCONNECT_DRIVER,
+						get_order(sg_dma_len(sgl)),
+						DMA_BIDIRECTIONAL);
+	}
+}
+
+static int xe_bo_sg_to_dma_addr_array(struct sg_table *sg, struct xe_bo *bo)
+{
+	struct xe_device *xe = xe_bo_device(bo);
+	struct drm_pagemap_addr *dma_addr;
+	resource_size_t io_start;
+	struct pci_dev *pdev;
+	phys_addr_t phys;
+	int vfid;
+
+	if (!IS_SRIOV_PF(xe))
+		return 0;
+
+	phys = sg_dma_address(sg->sgl);
+	if (page_is_ram(PFN_DOWN(phys)))
+		return 0;
+
+	pdev = xe_find_vf_dev(xe, phys);
+	if (!pdev)
+		return 0;
+
+	vfid = pci_iov_vf_id(pdev);
+	if (vfid < 0)
+		return 0;
+
+	dma_addr = kmalloc_array(sg->nents, sizeof(*dma_addr), GFP_KERNEL);
+	if (!dma_addr)
+		return -ENOMEM;
+
+	bo->is_devmem_external = true;
+	bo->dma_data.dma_addr = dma_addr;
+	io_start = pci_resource_start(pdev, LMEM_BAR);
+	xe_bo_translate_io_to_dpa(bo, sg, io_start, vfid);
+
+	return 0;
+}
+
 /*
  * The dma-buf map_attachment() / unmap_attachment() is hooked up here.
  * Note that unmapping the attachment is deferred to the next
@@ -697,6 +784,7 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
 	struct xe_device *xe = ttm_to_xe_device(ttm_bo->bdev);
 	bool device_unplugged = drm_dev_is_unplugged(&xe->drm);
 	struct sg_table *sg;
+	int ret = 0;
 
 	xe_assert(xe, attach);
 	xe_assert(xe, ttm_bo->ttm);
@@ -721,13 +809,19 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
 	if (IS_ERR(sg))
 		return PTR_ERR(sg);
 
+	ret = xe_bo_sg_to_dma_addr_array(sg, ttm_to_xe_bo(ttm_bo));
+	if (ret < 0) {
+		dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
+		return ret;
+	}
+
 	ttm_bo->sg = sg;
 	xe_tt->sg = sg;
 
 out:
 	ttm_bo_move_null(ttm_bo, new_res);
 
-	return 0;
+	return ret;
 }
 
 /**
@@ -1554,6 +1648,11 @@ static void xe_ttm_bo_delete_mem_notify(struct ttm_buffer_object *ttm_bo)
 
 		dma_buf_unmap_attachment(ttm_bo->base.import_attach, ttm_bo->sg,
 					 DMA_BIDIRECTIONAL);
+
+		if (bo->is_devmem_external) {
+			xe_bo_put(bo->dma_data.lmem_obj);
+			kfree(bo->dma_data.dma_addr);
+		}
 		ttm_bo->sg = NULL;
 		xe_tt->sg = NULL;
 	}
diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
index d4fe3c8dca5b..8e416c4ffbca 100644
--- a/drivers/gpu/drm/xe/xe_bo_types.h
+++ b/drivers/gpu/drm/xe/xe_bo_types.h
@@ -108,6 +108,18 @@ struct xe_bo {
 	 * from default
 	 */
 	u64 min_align;
+
+	/**
+	 * @is_devmem_external: Whether this BO is an imported dma-buf that
+	 * is LMEM based.
+	 */
+	bool is_devmem_external;
+
+	/**
+	 * @dma_data: DMA related data for an imported dmabuf BO that is LMEM
+	 * based.
+	 */
+	struct xe_sriov_dma_data dma_data;
 };
 
 #endif
diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_types.h b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
index 956a88f9f213..6d5f923f7fc4 100644
--- a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
+++ b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
@@ -11,6 +11,8 @@
 
 #include "xe_sriov_pf_service_types.h"
 
+struct xe_bo;
+
 /**
  * struct xe_sriov_metadata - per-VF device level metadata
  */
@@ -42,4 +44,21 @@ struct xe_device_pf {
 	struct xe_sriov_metadata *vfs;
 };
 
+/**
+ * struct xe_sriov_dma_data - DMA related data for LMEM based imported dmabuf
+ * BOs that are associated with a sriov VF.
+ *
+ * The data in this structure is valid only if driver is running in the
+ * @XE_SRIOV_MODE_PF mode.
+ */
+struct xe_sriov_dma_data {
+	/**
+	 * @dma_addr: An array to store DMA addresses (DPAs) for imported
+	 * dmabuf BOs that are LMEM based.
+	 */
+	struct drm_pagemap_addr *dma_addr;
+
+	/** @lmem_obj: Ref taken on the LMEM obj that backs a VF's quota */
+	struct xe_bo *lmem_obj;
+};
 #endif
-- 
2.50.1

[PATCH v4 5/5] drm/xe/pt: Add an additional check for dmabuf BOs while doing bind

[Vivek Kasireddy]

If a BO's is_devmem_external flag is set, it means that it is an
imported dmabuf BO that has a backing store in VRAM. Therefore, in
this case, need to iterate over its dma_addr array.

v2:
- Use a cursor to iterate over the entries in the dma_addr array
  instead of relying on SG iterator (Matt)

v3:
- Since XE_PPGTT_PTE_DM is added to the PTE flags in all cases,
  remove the bo->is_devmem_external check added in v2

Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
 drivers/gpu/drm/xe/xe_pt.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
index 01eea8eb1779..a4b60fbcbc74 100644
--- a/drivers/gpu/drm/xe/xe_pt.c
+++ b/drivers/gpu/drm/xe/xe_pt.c
@@ -760,6 +760,10 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
 
 	xe_walk.default_vram_pte |= XE_PPGTT_PTE_DM;
 	xe_walk.dma_offset = bo ? vram_region_gpu_offset(bo->ttm.resource) : 0;
+
+	if (bo && bo->is_devmem_external)
+		xe_walk.dma_offset = 0;
+
 	if (!range)
 		xe_bo_assert_held(bo);
 
@@ -770,6 +774,10 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
 		else if (xe_bo_is_vram(bo) || xe_bo_is_stolen(bo))
 			xe_res_first(bo->ttm.resource, xe_vma_bo_offset(vma),
 				     xe_vma_size(vma), &curs);
+		else if (bo && bo->is_devmem_external)
+			xe_res_first_dma(bo->dma_data.dma_addr,
+					 xe_vma_bo_offset(vma),
+					 xe_vma_size(vma), &curs);
 		else
 			xe_res_first_sg(xe_bo_sg(bo), xe_vma_bo_offset(vma),
 					xe_vma_size(vma), &curs);
-- 
2.50.1

✗ CI.checkpatch: warning for drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[Patchwork]

== Series Details ==

Series: drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds
URL   : https://patchwork.freedesktop.org/series/154504/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
fbd08a78c3a3bb17964db2a326514c69c1dca660
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 4c414ec01c1b2f14058d337599aca3a1c1cc4f42
Author: Vivek Kasireddy <vivek.kasireddy@intel.com>
Date:   Mon Sep 15 00:21:09 2025 -0700

    drm/xe/pt: Add an additional check for dmabuf BOs while doing bind
    
    If a BO's is_devmem_external flag is set, it means that it is an
    imported dmabuf BO that has a backing store in VRAM. Therefore, in
    this case, need to iterate over its dma_addr array.
    
    v2:
    - Use a cursor to iterate over the entries in the dma_addr array
      instead of relying on SG iterator (Matt)
    
    v3:
    - Since XE_PPGTT_PTE_DM is added to the PTE flags in all cases,
      remove the bo->is_devmem_external check added in v2
    
    Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
+ /mt/dim checkpatch 36a8f6b405f4a0def4462366cd17992897e1362b drm-intel
11860c6601a3 PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs
d9df4f3dba24 drm/xe/dmabuf: Don't migrate BO to System RAM if P2P check succeeds
744393c72b10 drm/xe/pf: Add a helper function to get a VF's backing object in LMEM
e23f55318bba drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs
-:90: CHECK:LINE_SPACING: Please don't use multiple blank lines
#90: FILE: drivers/gpu/drm/xe/xe_bo.c:706:
+
+

-:111: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#111: FILE: drivers/gpu/drm/xe/xe_bo.c:727:
+		bo->dma_data.dma_addr[i] = drm_pagemap_addr_encode(addr,
+						DRM_INTERCONNECT_DRIVER,

total: 0 errors, 0 warnings, 2 checks, 195 lines checked
4c414ec01c1b drm/xe/pt: Add an additional check for dmabuf BOs while doing bind

✓ CI.KUnit: success for drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[Patchwork]

== Series Details ==

Series: drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds
URL   : https://patchwork.freedesktop.org/series/154504/
State : success

== Summary ==

+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
[07:32:31] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[07:32:35] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[07:33:04] Starting KUnit Kernel (1/1)...
[07:33:04] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[07:33:04] ================== guc_buf (11 subtests) ===================
[07:33:04] [PASSED] test_smallest
[07:33:04] [PASSED] test_largest
[07:33:04] [PASSED] test_granular
[07:33:04] [PASSED] test_unique
[07:33:04] [PASSED] test_overlap
[07:33:04] [PASSED] test_reusable
[07:33:04] [PASSED] test_too_big
[07:33:04] [PASSED] test_flush
[07:33:04] [PASSED] test_lookup
[07:33:04] [PASSED] test_data
[07:33:04] [PASSED] test_class
[07:33:04] ===================== [PASSED] guc_buf =====================
[07:33:04] =================== guc_dbm (7 subtests) ===================
[07:33:04] [PASSED] test_empty
[07:33:04] [PASSED] test_default
[07:33:04] ======================== test_size  ========================
[07:33:04] [PASSED] 4
[07:33:04] [PASSED] 8
[07:33:04] [PASSED] 32
[07:33:04] [PASSED] 256
[07:33:04] ==================== [PASSED] test_size ====================
[07:33:04] ======================= test_reuse  ========================
[07:33:04] [PASSED] 4
[07:33:04] [PASSED] 8
[07:33:04] [PASSED] 32
[07:33:04] [PASSED] 256
[07:33:04] =================== [PASSED] test_reuse ====================
[07:33:04] =================== test_range_overlap  ====================
[07:33:04] [PASSED] 4
[07:33:04] [PASSED] 8
[07:33:04] [PASSED] 32
[07:33:04] [PASSED] 256
[07:33:04] =============== [PASSED] test_range_overlap ================
[07:33:04] =================== test_range_compact  ====================
[07:33:04] [PASSED] 4
[07:33:04] [PASSED] 8
[07:33:04] [PASSED] 32
[07:33:04] [PASSED] 256
[07:33:04] =============== [PASSED] test_range_compact ================
[07:33:04] ==================== test_range_spare  =====================
[07:33:04] [PASSED] 4
[07:33:04] [PASSED] 8
[07:33:04] [PASSED] 32
[07:33:04] [PASSED] 256
[07:33:04] ================ [PASSED] test_range_spare =================
[07:33:04] ===================== [PASSED] guc_dbm =====================
[07:33:04] =================== guc_idm (6 subtests) ===================
[07:33:04] [PASSED] bad_init
[07:33:04] [PASSED] no_init
[07:33:04] [PASSED] init_fini
[07:33:04] [PASSED] check_used
[07:33:04] [PASSED] check_quota
[07:33:04] [PASSED] check_all
[07:33:04] ===================== [PASSED] guc_idm =====================
[07:33:04] ================== no_relay (3 subtests) ===================
[07:33:04] [PASSED] xe_drops_guc2pf_if_not_ready
[07:33:04] [PASSED] xe_drops_guc2vf_if_not_ready
[07:33:04] [PASSED] xe_rejects_send_if_not_ready
[07:33:04] ==================== [PASSED] no_relay =====================
[07:33:04] ================== pf_relay (14 subtests) ==================
[07:33:04] [PASSED] pf_rejects_guc2pf_too_short
[07:33:04] [PASSED] pf_rejects_guc2pf_too_long
[07:33:04] [PASSED] pf_rejects_guc2pf_no_payload
[07:33:04] [PASSED] pf_fails_no_payload
[07:33:04] [PASSED] pf_fails_bad_origin
[07:33:04] [PASSED] pf_fails_bad_type
[07:33:04] [PASSED] pf_txn_reports_error
[07:33:04] [PASSED] pf_txn_sends_pf2guc
[07:33:04] [PASSED] pf_sends_pf2guc
[07:33:04] [SKIPPED] pf_loopback_nop
[07:33:04] [SKIPPED] pf_loopback_echo
[07:33:04] [SKIPPED] pf_loopback_fail
[07:33:04] [SKIPPED] pf_loopback_busy
[07:33:04] [SKIPPED] pf_loopback_retry
[07:33:04] ==================== [PASSED] pf_relay =====================
[07:33:04] ================== vf_relay (3 subtests) ===================
[07:33:04] [PASSED] vf_rejects_guc2vf_too_short
[07:33:04] [PASSED] vf_rejects_guc2vf_too_long
[07:33:04] [PASSED] vf_rejects_guc2vf_no_payload
[07:33:04] ==================== [PASSED] vf_relay =====================
[07:33:04] ===================== lmtt (1 subtest) =====================
[07:33:04] ======================== test_ops  =========================
[07:33:04] [PASSED] 2-level
[07:33:04] [PASSED] multi-level
[07:33:04] ==================== [PASSED] test_ops =====================
[07:33:04] ====================== [PASSED] lmtt =======================
[07:33:04] ================= pf_service (11 subtests) =================
[07:33:04] [PASSED] pf_negotiate_any
[07:33:04] [PASSED] pf_negotiate_base_match
[07:33:04] [PASSED] pf_negotiate_base_newer
[07:33:04] [PASSED] pf_negotiate_base_next
[07:33:04] [SKIPPED] pf_negotiate_base_older
[07:33:04] [PASSED] pf_negotiate_base_prev
[07:33:04] [PASSED] pf_negotiate_latest_match
[07:33:04] [PASSED] pf_negotiate_latest_newer
[07:33:04] [PASSED] pf_negotiate_latest_next
[07:33:04] [SKIPPED] pf_negotiate_latest_older
[07:33:04] [SKIPPED] pf_negotiate_latest_prev
[07:33:04] =================== [PASSED] pf_service ====================
[07:33:04] =================== xe_mocs (2 subtests) ===================
[07:33:04] ================ xe_live_mocs_kernel_kunit  ================
[07:33:04] =========== [SKIPPED] xe_live_mocs_kernel_kunit ============
[07:33:04] ================ xe_live_mocs_reset_kunit  =================
[07:33:04] ============ [SKIPPED] xe_live_mocs_reset_kunit ============
[07:33:04] ==================== [SKIPPED] xe_mocs =====================
[07:33:04] ================= xe_migrate (2 subtests) ==================
[07:33:04] ================= xe_migrate_sanity_kunit  =================
[07:33:04] ============ [SKIPPED] xe_migrate_sanity_kunit =============
[07:33:04] ================== xe_validate_ccs_kunit  ==================
[07:33:04] ============= [SKIPPED] xe_validate_ccs_kunit ==============
[07:33:04] =================== [SKIPPED] xe_migrate ===================
[07:33:04] ================== xe_dma_buf (1 subtest) ==================
[07:33:04] ==================== xe_dma_buf_kunit  =====================
[07:33:04] ================ [SKIPPED] xe_dma_buf_kunit ================
[07:33:04] =================== [SKIPPED] xe_dma_buf ===================
[07:33:04] ================= xe_bo_shrink (1 subtest) =================
[07:33:04] =================== xe_bo_shrink_kunit  ====================
[07:33:04] =============== [SKIPPED] xe_bo_shrink_kunit ===============
[07:33:04] ================== [SKIPPED] xe_bo_shrink ==================
[07:33:04] ==================== xe_bo (2 subtests) ====================
[07:33:04] ================== xe_ccs_migrate_kunit  ===================
[07:33:04] ============== [SKIPPED] xe_ccs_migrate_kunit ==============
[07:33:04] ==================== xe_bo_evict_kunit  ====================
[07:33:04] =============== [SKIPPED] xe_bo_evict_kunit ================
[07:33:04] ===================== [SKIPPED] xe_bo ======================
[07:33:04] ==================== args (11 subtests) ====================
[07:33:04] [PASSED] count_args_test
[07:33:04] [PASSED] call_args_example
[07:33:04] [PASSED] call_args_test
[07:33:04] [PASSED] drop_first_arg_example
[07:33:04] [PASSED] drop_first_arg_test
[07:33:04] [PASSED] first_arg_example
[07:33:04] [PASSED] first_arg_test
[07:33:04] [PASSED] last_arg_example
[07:33:04] [PASSED] last_arg_test
[07:33:04] [PASSED] pick_arg_example
[07:33:04] [PASSED] sep_comma_example
[07:33:04] ====================== [PASSED] args =======================
[07:33:04] =================== xe_pci (3 subtests) ====================
[07:33:04] ==================== check_graphics_ip  ====================
[07:33:04] [PASSED] 12.70 Xe_LPG
[07:33:04] [PASSED] 12.71 Xe_LPG
[07:33:04] [PASSED] 12.74 Xe_LPG+
[07:33:04] [PASSED] 20.01 Xe2_HPG
[07:33:04] [PASSED] 20.02 Xe2_HPG
[07:33:04] [PASSED] 20.04 Xe2_LPG
[07:33:04] [PASSED] 30.00 Xe3_LPG
[07:33:04] [PASSED] 30.01 Xe3_LPG
[07:33:04] [PASSED] 30.03 Xe3_LPG
[07:33:04] ================ [PASSED] check_graphics_ip ================
[07:33:04] ===================== check_media_ip  ======================
[07:33:04] [PASSED] 13.00 Xe_LPM+
[07:33:04] [PASSED] 13.01 Xe2_HPM
[07:33:04] [PASSED] 20.00 Xe2_LPM
[07:33:04] [PASSED] 30.00 Xe3_LPM
[07:33:04] [PASSED] 30.02 Xe3_LPM
[07:33:04] ================= [PASSED] check_media_ip ==================
[07:33:04] ================= check_platform_gt_count  =================
[07:33:04] [PASSED] 0x9A60 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A68 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A70 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A40 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A49 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A59 (TIGERLAKE)
[07:33:04] [PASSED] 0x9A78 (TIGERLAKE)
[07:33:04] [PASSED] 0x9AC0 (TIGERLAKE)
[07:33:04] [PASSED] 0x9AC9 (TIGERLAKE)
[07:33:04] [PASSED] 0x9AD9 (TIGERLAKE)
[07:33:04] [PASSED] 0x9AF8 (TIGERLAKE)
[07:33:04] [PASSED] 0x4C80 (ROCKETLAKE)
[07:33:04] [PASSED] 0x4C8A (ROCKETLAKE)
[07:33:04] [PASSED] 0x4C8B (ROCKETLAKE)
[07:33:04] [PASSED] 0x4C8C (ROCKETLAKE)
[07:33:04] [PASSED] 0x4C90 (ROCKETLAKE)
[07:33:04] [PASSED] 0x4C9A (ROCKETLAKE)
[07:33:04] [PASSED] 0x4680 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4682 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4688 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x468A (ALDERLAKE_S)
[07:33:04] [PASSED] 0x468B (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4690 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4692 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4693 (ALDERLAKE_S)
[07:33:04] [PASSED] 0x46A0 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46A1 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46A2 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46A3 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46A6 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46A8 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46AA (ALDERLAKE_P)
[07:33:04] [PASSED] 0x462A (ALDERLAKE_P)
[07:33:04] [PASSED] 0x4626 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x4628 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46B0 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46B1 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46B2 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46B3 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46C0 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46C1 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46C2 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46C3 (ALDERLAKE_P)
[07:33:04] [PASSED] 0x46D0 (ALDERLAKE_N)
[07:33:04] [PASSED] 0x46D1 (ALDERLAKE_N)
[07:33:04] [PASSED] 0x46D2 (ALDERLAKE_N)
[07:33:04] [PASSED] 0x46D3 (ALDERLAKE_N)
[07:33:04] [PASSED] 0x46D4 (ALDERLAKE_N)
[07:33:04] [PASSED] 0xA721 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7A1 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7A9 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7AC (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7AD (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA720 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7A0 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7A8 (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7AA (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA7AB (ALDERLAKE_P)
[07:33:04] [PASSED] 0xA780 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA781 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA782 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA783 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA788 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA789 (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA78A (ALDERLAKE_S)
[07:33:04] [PASSED] 0xA78B (ALDERLAKE_S)
[07:33:04] [PASSED] 0x4905 (DG1)
[07:33:04] [PASSED] 0x4906 (DG1)
[07:33:04] [PASSED] 0x4907 (DG1)
[07:33:04] [PASSED] 0x4908 (DG1)
[07:33:04] [PASSED] 0x4909 (DG1)
[07:33:04] [PASSED] 0x56C0 (DG2)
[07:33:04] [PASSED] 0x56C2 (DG2)
[07:33:04] [PASSED] 0x56C1 (DG2)
[07:33:04] [PASSED] 0x7D51 (METEORLAKE)
[07:33:04] [PASSED] 0x7DD1 (METEORLAKE)
[07:33:04] [PASSED] 0x7D41 (METEORLAKE)
[07:33:04] [PASSED] 0x7D67 (METEORLAKE)
[07:33:04] [PASSED] 0xB640 (METEORLAKE)
[07:33:04] [PASSED] 0x56A0 (DG2)
[07:33:04] [PASSED] 0x56A1 (DG2)
[07:33:04] [PASSED] 0x56A2 (DG2)
[07:33:04] [PASSED] 0x56BE (DG2)
[07:33:04] [PASSED] 0x56BF (DG2)
[07:33:04] [PASSED] 0x5690 (DG2)
[07:33:04] [PASSED] 0x5691 (DG2)
[07:33:04] [PASSED] 0x5692 (DG2)
[07:33:04] [PASSED] 0x56A5 (DG2)
[07:33:04] [PASSED] 0x56A6 (DG2)
[07:33:04] [PASSED] 0x56B0 (DG2)
[07:33:04] [PASSED] 0x56B1 (DG2)
[07:33:04] [PASSED] 0x56BA (DG2)
[07:33:04] [PASSED] 0x56BB (DG2)
[07:33:04] [PASSED] 0x56BC (DG2)
[07:33:04] [PASSED] 0x56BD (DG2)
[07:33:04] [PASSED] 0x5693 (DG2)
[07:33:04] [PASSED] 0x5694 (DG2)
[07:33:04] [PASSED] 0x5695 (DG2)
[07:33:04] [PASSED] 0x56A3 (DG2)
[07:33:04] [PASSED] 0x56A4 (DG2)
[07:33:04] [PASSED] 0x56B2 (DG2)
[07:33:04] [PASSED] 0x56B3 (DG2)
[07:33:04] [PASSED] 0x5696 (DG2)
[07:33:04] [PASSED] 0x5697 (DG2)
[07:33:04] [PASSED] 0xB69 (PVC)
[07:33:04] [PASSED] 0xB6E (PVC)
[07:33:04] [PASSED] 0xBD4 (PVC)
[07:33:04] [PASSED] 0xBD5 (PVC)
[07:33:04] [PASSED] 0xBD6 (PVC)
[07:33:04] [PASSED] 0xBD7 (PVC)
[07:33:04] [PASSED] 0xBD8 (PVC)
[07:33:04] [PASSED] 0xBD9 (PVC)
[07:33:04] [PASSED] 0xBDA (PVC)
[07:33:04] [PASSED] 0xBDB (PVC)
[07:33:04] [PASSED] 0xBE0 (PVC)
[07:33:04] [PASSED] 0xBE1 (PVC)
[07:33:04] [PASSED] 0xBE5 (PVC)
[07:33:04] [PASSED] 0x7D40 (METEORLAKE)
[07:33:04] [PASSED] 0x7D45 (METEORLAKE)
[07:33:04] [PASSED] 0x7D55 (METEORLAKE)
[07:33:04] [PASSED] 0x7D60 (METEORLAKE)
[07:33:04] [PASSED] 0x7DD5 (METEORLAKE)
[07:33:04] [PASSED] 0x6420 (LUNARLAKE)
[07:33:04] [PASSED] 0x64A0 (LUNARLAKE)
[07:33:04] [PASSED] 0x64B0 (LUNARLAKE)
[07:33:04] [PASSED] 0xE202 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE209 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE20B (BATTLEMAGE)
[07:33:04] [PASSED] 0xE20C (BATTLEMAGE)
[07:33:04] [PASSED] 0xE20D (BATTLEMAGE)
[07:33:04] [PASSED] 0xE210 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE211 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE212 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE216 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE220 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE221 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE222 (BATTLEMAGE)
[07:33:04] [PASSED] 0xE223 (BATTLEMAGE)
[07:33:04] [PASSED] 0xB080 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB081 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB082 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB083 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB084 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB085 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB086 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB087 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB08F (PANTHERLAKE)
[07:33:04] [PASSED] 0xB090 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB0A0 (PANTHERLAKE)
[07:33:04] [PASSED] 0xB0B0 (PANTHERLAKE)
[07:33:04] [PASSED] 0xFD80 (PANTHERLAKE)
[07:33:04] [PASSED] 0xFD81 (PANTHERLAKE)
[07:33:04] ============= [PASSED] check_platform_gt_count =============
[07:33:04] ===================== [PASSED] xe_pci ======================
[07:33:04] =================== xe_rtp (2 subtests) ====================
[07:33:04] =============== xe_rtp_process_to_sr_tests  ================
[07:33:04] [PASSED] coalesce-same-reg
[07:33:04] [PASSED] no-match-no-add
[07:33:04] [PASSED] match-or
[07:33:04] [PASSED] match-or-xfail
[07:33:04] [PASSED] no-match-no-add-multiple-rules
[07:33:04] [PASSED] two-regs-two-entries
[07:33:04] [PASSED] clr-one-set-other
[07:33:04] [PASSED] set-field
[07:33:04] [PASSED] conflict-duplicate
[07:33:04] [PASSED] conflict-not-disjoint
[07:33:04] [PASSED] conflict-reg-type
[07:33:04] =========== [PASSED] xe_rtp_process_to_sr_tests ============
[07:33:04] ================== xe_rtp_process_tests  ===================
[07:33:04] [PASSED] active1
[07:33:04] [PASSED] active2
[07:33:04] [PASSED] active-inactive
[07:33:04] [PASSED] inactive-active
[07:33:04] [PASSED] inactive-1st_or_active-inactive
[07:33:04] [PASSED] inactive-2nd_or_active-inactive
[07:33:04] [PASSED] inactive-last_or_active-inactive
[07:33:04] [PASSED] inactive-no_or_active-inactive
[07:33:04] ============== [PASSED] xe_rtp_process_tests ===============
[07:33:04] ===================== [PASSED] xe_rtp ======================
[07:33:04] ==================== xe_wa (1 subtest) =====================
[07:33:04] ======================== xe_wa_gt  =========================
[07:33:04] [PASSED] TIGERLAKE B0
[07:33:04] [PASSED] DG1 A0
[07:33:04] [PASSED] DG1 B0
[07:33:04] [PASSED] ALDERLAKE_S A0
[07:33:04] [PASSED] ALDERLAKE_S B0
[07:33:04] [PASSED] ALDERLAKE_S C0
[07:33:04] [PASSED] ALDERLAKE_S D0
[07:33:04] [PASSED] ALDERLAKE_P A0
[07:33:04] [PASSED] ALDERLAKE_P B0
[07:33:04] [PASSED] ALDERLAKE_P C0
[07:33:04] [PASSED] ALDERLAKE_S RPLS D0
[07:33:04] [PASSED] ALDERLAKE_P RPLU E0
[07:33:04] [PASSED] DG2 G10 C0
[07:33:04] [PASSED] DG2 G11 B1
[07:33:04] [PASSED] DG2 G12 A1
[07:33:04] [PASSED] METEORLAKE 12.70(Xe_LPG) A0 13.00(Xe_LPM+) A0
[07:33:04] [PASSED] METEORLAKE 12.71(Xe_LPG) A0 13.00(Xe_LPM+) A0
[07:33:04] [PASSED] METEORLAKE 12.74(Xe_LPG+) A0 13.00(Xe_LPM+) A0
[07:33:04] [PASSED] LUNARLAKE 20.04(Xe2_LPG) A0 20.00(Xe2_LPM) A0
stty: 'standard input': Inappropriate ioctl for device
[07:33:04] [PASSED] LUNARLAKE 20.04(Xe2_LPG) B0 20.00(Xe2_LPM) A0
[07:33:04] [PASSED] BATTLEMAGE 20.01(Xe2_HPG) A0 13.01(Xe2_HPM) A1
[07:33:04] [PASSED] PANTHERLAKE 30.00(Xe3_LPG) A0 30.00(Xe3_LPM) A0
[07:33:04] ==================== [PASSED] xe_wa_gt =====================
[07:33:04] ====================== [PASSED] xe_wa ======================
[07:33:04] ============================================================
[07:33:04] Testing complete. Ran 298 tests: passed: 282, skipped: 16
[07:33:04] Elapsed time: 33.440s total, 4.238s configuring, 28.836s building, 0.323s running

+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig
[07:33:04] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[07:33:06] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[07:33:29] Starting KUnit Kernel (1/1)...
[07:33:29] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[07:33:29] == drm_test_atomic_get_connector_for_encoder (1 subtest) ===
[07:33:29] [PASSED] drm_test_drm_atomic_get_connector_for_encoder
[07:33:29] ==== [PASSED] drm_test_atomic_get_connector_for_encoder ====
[07:33:29] =========== drm_validate_clone_mode (2 subtests) ===========
[07:33:29] ============== drm_test_check_in_clone_mode  ===============
[07:33:29] [PASSED] in_clone_mode
[07:33:29] [PASSED] not_in_clone_mode
[07:33:29] ========== [PASSED] drm_test_check_in_clone_mode ===========
[07:33:29] =============== drm_test_check_valid_clones  ===============
[07:33:29] [PASSED] not_in_clone_mode
[07:33:29] [PASSED] valid_clone
[07:33:29] [PASSED] invalid_clone
[07:33:29] =========== [PASSED] drm_test_check_valid_clones ===========
[07:33:29] ============= [PASSED] drm_validate_clone_mode =============
[07:33:29] ============= drm_validate_modeset (1 subtest) =============
[07:33:29] [PASSED] drm_test_check_connector_changed_modeset
[07:33:29] ============== [PASSED] drm_validate_modeset ===============
[07:33:29] ====== drm_test_bridge_get_current_state (2 subtests) ======
[07:33:29] [PASSED] drm_test_drm_bridge_get_current_state_atomic
[07:33:29] [PASSED] drm_test_drm_bridge_get_current_state_legacy
[07:33:29] ======== [PASSED] drm_test_bridge_get_current_state ========
[07:33:29] ====== drm_test_bridge_helper_reset_crtc (3 subtests) ======
[07:33:29] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic
[07:33:29] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic_disabled
[07:33:29] [PASSED] drm_test_drm_bridge_helper_reset_crtc_legacy
[07:33:29] ======== [PASSED] drm_test_bridge_helper_reset_crtc ========
[07:33:29] ============== drm_bridge_alloc (2 subtests) ===============
[07:33:29] [PASSED] drm_test_drm_bridge_alloc_basic
[07:33:29] [PASSED] drm_test_drm_bridge_alloc_get_put
[07:33:29] ================ [PASSED] drm_bridge_alloc =================
[07:33:29] ================== drm_buddy (7 subtests) ==================
[07:33:29] [PASSED] drm_test_buddy_alloc_limit
[07:33:29] [PASSED] drm_test_buddy_alloc_optimistic
[07:33:29] [PASSED] drm_test_buddy_alloc_pessimistic
[07:33:29] [PASSED] drm_test_buddy_alloc_pathological
[07:33:29] [PASSED] drm_test_buddy_alloc_contiguous
[07:33:29] [PASSED] drm_test_buddy_alloc_clear
[07:33:29] [PASSED] drm_test_buddy_alloc_range_bias
[07:33:29] ==================== [PASSED] drm_buddy ====================
[07:33:29] ============= drm_cmdline_parser (40 subtests) =============
[07:33:29] [PASSED] drm_test_cmdline_force_d_only
[07:33:29] [PASSED] drm_test_cmdline_force_D_only_dvi
[07:33:29] [PASSED] drm_test_cmdline_force_D_only_hdmi
[07:33:29] [PASSED] drm_test_cmdline_force_D_only_not_digital
[07:33:29] [PASSED] drm_test_cmdline_force_e_only
[07:33:29] [PASSED] drm_test_cmdline_res
[07:33:29] [PASSED] drm_test_cmdline_res_vesa
[07:33:29] [PASSED] drm_test_cmdline_res_vesa_rblank
[07:33:29] [PASSED] drm_test_cmdline_res_rblank
[07:33:29] [PASSED] drm_test_cmdline_res_bpp
[07:33:29] [PASSED] drm_test_cmdline_res_refresh
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_margins
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital
[07:33:29] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on
[07:33:29] [PASSED] drm_test_cmdline_res_margins_force_on
[07:33:29] [PASSED] drm_test_cmdline_res_vesa_margins
[07:33:29] [PASSED] drm_test_cmdline_name
[07:33:29] [PASSED] drm_test_cmdline_name_bpp
[07:33:29] [PASSED] drm_test_cmdline_name_option
[07:33:29] [PASSED] drm_test_cmdline_name_bpp_option
[07:33:29] [PASSED] drm_test_cmdline_rotate_0
[07:33:29] [PASSED] drm_test_cmdline_rotate_90
[07:33:29] [PASSED] drm_test_cmdline_rotate_180
[07:33:29] [PASSED] drm_test_cmdline_rotate_270
[07:33:29] [PASSED] drm_test_cmdline_hmirror
[07:33:29] [PASSED] drm_test_cmdline_vmirror
[07:33:29] [PASSED] drm_test_cmdline_margin_options
[07:33:29] [PASSED] drm_test_cmdline_multiple_options
[07:33:29] [PASSED] drm_test_cmdline_bpp_extra_and_option
[07:33:29] [PASSED] drm_test_cmdline_extra_and_option
[07:33:29] [PASSED] drm_test_cmdline_freestanding_options
[07:33:29] [PASSED] drm_test_cmdline_freestanding_force_e_and_options
[07:33:29] [PASSED] drm_test_cmdline_panel_orientation
[07:33:29] ================ drm_test_cmdline_invalid  =================
[07:33:29] [PASSED] margin_only
[07:33:29] [PASSED] interlace_only
[07:33:29] [PASSED] res_missing_x
[07:33:29] [PASSED] res_missing_y
[07:33:29] [PASSED] res_bad_y
[07:33:29] [PASSED] res_missing_y_bpp
[07:33:29] [PASSED] res_bad_bpp
[07:33:29] [PASSED] res_bad_refresh
[07:33:29] [PASSED] res_bpp_refresh_force_on_off
[07:33:29] [PASSED] res_invalid_mode
[07:33:29] [PASSED] res_bpp_wrong_place_mode
[07:33:29] [PASSED] name_bpp_refresh
[07:33:29] [PASSED] name_refresh
[07:33:29] [PASSED] name_refresh_wrong_mode
[07:33:29] [PASSED] name_refresh_invalid_mode
[07:33:29] [PASSED] rotate_multiple
[07:33:29] [PASSED] rotate_invalid_val
[07:33:29] [PASSED] rotate_truncated
[07:33:29] [PASSED] invalid_option
[07:33:29] [PASSED] invalid_tv_option
[07:33:29] [PASSED] truncated_tv_option
[07:33:29] ============ [PASSED] drm_test_cmdline_invalid =============
[07:33:29] =============== drm_test_cmdline_tv_options  ===============
[07:33:29] [PASSED] NTSC
[07:33:29] [PASSED] NTSC_443
[07:33:29] [PASSED] NTSC_J
[07:33:29] [PASSED] PAL
[07:33:29] [PASSED] PAL_M
[07:33:29] [PASSED] PAL_N
[07:33:29] [PASSED] SECAM
[07:33:29] [PASSED] MONO_525
[07:33:29] [PASSED] MONO_625
[07:33:29] =========== [PASSED] drm_test_cmdline_tv_options ===========
[07:33:29] =============== [PASSED] drm_cmdline_parser ================
[07:33:29] ========== drmm_connector_hdmi_init (20 subtests) ==========
[07:33:29] [PASSED] drm_test_connector_hdmi_init_valid
[07:33:29] [PASSED] drm_test_connector_hdmi_init_bpc_8
[07:33:29] [PASSED] drm_test_connector_hdmi_init_bpc_10
[07:33:29] [PASSED] drm_test_connector_hdmi_init_bpc_12
[07:33:29] [PASSED] drm_test_connector_hdmi_init_bpc_invalid
[07:33:29] [PASSED] drm_test_connector_hdmi_init_bpc_null
[07:33:29] [PASSED] drm_test_connector_hdmi_init_formats_empty
[07:33:29] [PASSED] drm_test_connector_hdmi_init_formats_no_rgb
[07:33:29] === drm_test_connector_hdmi_init_formats_yuv420_allowed  ===
[07:33:29] [PASSED] supported_formats=0x9 yuv420_allowed=1
[07:33:29] [PASSED] supported_formats=0x9 yuv420_allowed=0
[07:33:29] [PASSED] supported_formats=0x3 yuv420_allowed=1
[07:33:29] [PASSED] supported_formats=0x3 yuv420_allowed=0
[07:33:29] === [PASSED] drm_test_connector_hdmi_init_formats_yuv420_allowed ===
[07:33:29] [PASSED] drm_test_connector_hdmi_init_null_ddc
[07:33:29] [PASSED] drm_test_connector_hdmi_init_null_product
[07:33:29] [PASSED] drm_test_connector_hdmi_init_null_vendor
[07:33:29] [PASSED] drm_test_connector_hdmi_init_product_length_exact
[07:33:29] [PASSED] drm_test_connector_hdmi_init_product_length_too_long
[07:33:29] [PASSED] drm_test_connector_hdmi_init_product_valid
[07:33:29] [PASSED] drm_test_connector_hdmi_init_vendor_length_exact
[07:33:29] [PASSED] drm_test_connector_hdmi_init_vendor_length_too_long
[07:33:29] [PASSED] drm_test_connector_hdmi_init_vendor_valid
[07:33:29] ========= drm_test_connector_hdmi_init_type_valid  =========
[07:33:29] [PASSED] HDMI-A
[07:33:29] [PASSED] HDMI-B
[07:33:29] ===== [PASSED] drm_test_connector_hdmi_init_type_valid =====
[07:33:29] ======== drm_test_connector_hdmi_init_type_invalid  ========
[07:33:29] [PASSED] Unknown
[07:33:29] [PASSED] VGA
[07:33:29] [PASSED] DVI-I
[07:33:29] [PASSED] DVI-D
[07:33:29] [PASSED] DVI-A
[07:33:29] [PASSED] Composite
[07:33:29] [PASSED] SVIDEO
[07:33:29] [PASSED] LVDS
[07:33:29] [PASSED] Component
[07:33:29] [PASSED] DIN
[07:33:29] [PASSED] DP
[07:33:29] [PASSED] TV
[07:33:29] [PASSED] eDP
[07:33:29] [PASSED] Virtual
[07:33:29] [PASSED] DSI
[07:33:29] [PASSED] DPI
[07:33:29] [PASSED] Writeback
[07:33:29] [PASSED] SPI
[07:33:29] [PASSED] USB
[07:33:29] ==== [PASSED] drm_test_connector_hdmi_init_type_invalid ====
[07:33:29] ============ [PASSED] drmm_connector_hdmi_init =============
[07:33:29] ============= drmm_connector_init (3 subtests) =============
[07:33:29] [PASSED] drm_test_drmm_connector_init
[07:33:29] [PASSED] drm_test_drmm_connector_init_null_ddc
[07:33:29] ========= drm_test_drmm_connector_init_type_valid  =========
[07:33:29] [PASSED] Unknown
[07:33:29] [PASSED] VGA
[07:33:29] [PASSED] DVI-I
[07:33:29] [PASSED] DVI-D
[07:33:29] [PASSED] DVI-A
[07:33:29] [PASSED] Composite
[07:33:29] [PASSED] SVIDEO
[07:33:29] [PASSED] LVDS
[07:33:29] [PASSED] Component
[07:33:29] [PASSED] DIN
[07:33:29] [PASSED] DP
[07:33:29] [PASSED] HDMI-A
[07:33:29] [PASSED] HDMI-B
[07:33:29] [PASSED] TV
[07:33:29] [PASSED] eDP
[07:33:29] [PASSED] Virtual
[07:33:29] [PASSED] DSI
[07:33:29] [PASSED] DPI
[07:33:29] [PASSED] Writeback
[07:33:29] [PASSED] SPI
[07:33:29] [PASSED] USB
[07:33:29] ===== [PASSED] drm_test_drmm_connector_init_type_valid =====
[07:33:29] =============== [PASSED] drmm_connector_init ===============
[07:33:29] ========= drm_connector_dynamic_init (6 subtests) ==========
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_init
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_init_null_ddc
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_init_not_added
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_init_properties
[07:33:29] ===== drm_test_drm_connector_dynamic_init_type_valid  ======
[07:33:29] [PASSED] Unknown
[07:33:29] [PASSED] VGA
[07:33:29] [PASSED] DVI-I
[07:33:29] [PASSED] DVI-D
[07:33:29] [PASSED] DVI-A
[07:33:29] [PASSED] Composite
[07:33:29] [PASSED] SVIDEO
[07:33:29] [PASSED] LVDS
[07:33:29] [PASSED] Component
[07:33:29] [PASSED] DIN
[07:33:29] [PASSED] DP
[07:33:29] [PASSED] HDMI-A
[07:33:29] [PASSED] HDMI-B
[07:33:29] [PASSED] TV
[07:33:29] [PASSED] eDP
[07:33:29] [PASSED] Virtual
[07:33:29] [PASSED] DSI
[07:33:29] [PASSED] DPI
[07:33:29] [PASSED] Writeback
[07:33:29] [PASSED] SPI
[07:33:29] [PASSED] USB
[07:33:29] = [PASSED] drm_test_drm_connector_dynamic_init_type_valid ==
[07:33:29] ======== drm_test_drm_connector_dynamic_init_name  =========
[07:33:29] [PASSED] Unknown
[07:33:29] [PASSED] VGA
[07:33:29] [PASSED] DVI-I
[07:33:29] [PASSED] DVI-D
[07:33:29] [PASSED] DVI-A
[07:33:29] [PASSED] Composite
[07:33:29] [PASSED] SVIDEO
[07:33:29] [PASSED] LVDS
[07:33:29] [PASSED] Component
[07:33:29] [PASSED] DIN
[07:33:29] [PASSED] DP
[07:33:29] [PASSED] HDMI-A
[07:33:29] [PASSED] HDMI-B
[07:33:29] [PASSED] TV
[07:33:29] [PASSED] eDP
[07:33:29] [PASSED] Virtual
[07:33:29] [PASSED] DSI
[07:33:29] [PASSED] DPI
[07:33:29] [PASSED] Writeback
[07:33:29] [PASSED] SPI
[07:33:29] [PASSED] USB
[07:33:29] ==== [PASSED] drm_test_drm_connector_dynamic_init_name =====
[07:33:29] =========== [PASSED] drm_connector_dynamic_init ============
[07:33:29] ==== drm_connector_dynamic_register_early (4 subtests) =====
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_early_on_list
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_early_defer
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_early_no_init
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_early_no_mode_object
[07:33:29] ====== [PASSED] drm_connector_dynamic_register_early =======
[07:33:29] ======= drm_connector_dynamic_register (7 subtests) ========
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_on_list
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_no_defer
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_no_init
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_mode_object
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_sysfs
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_sysfs_name
[07:33:29] [PASSED] drm_test_drm_connector_dynamic_register_debugfs
[07:33:29] ========= [PASSED] drm_connector_dynamic_register ==========
[07:33:29] = drm_connector_attach_broadcast_rgb_property (2 subtests) =
[07:33:29] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property
[07:33:29] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector
[07:33:29] === [PASSED] drm_connector_attach_broadcast_rgb_property ===
[07:33:29] ========== drm_get_tv_mode_from_name (2 subtests) ==========
[07:33:29] ========== drm_test_get_tv_mode_from_name_valid  ===========
[07:33:29] [PASSED] NTSC
[07:33:29] [PASSED] NTSC-443
[07:33:29] [PASSED] NTSC-J
[07:33:29] [PASSED] PAL
[07:33:29] [PASSED] PAL-M
[07:33:29] [PASSED] PAL-N
[07:33:29] [PASSED] SECAM
[07:33:29] [PASSED] Mono
[07:33:29] ====== [PASSED] drm_test_get_tv_mode_from_name_valid =======
[07:33:29] [PASSED] drm_test_get_tv_mode_from_name_truncated
[07:33:29] ============ [PASSED] drm_get_tv_mode_from_name ============
[07:33:29] = drm_test_connector_hdmi_compute_mode_clock (12 subtests) =
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc_vic_1
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc_vic_1
[07:33:29] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_double
[07:33:29] = drm_test_connector_hdmi_compute_mode_clock_yuv420_valid  =
[07:33:29] [PASSED] VIC 96
[07:33:29] [PASSED] VIC 97
[07:33:29] [PASSED] VIC 101
[07:33:29] [PASSED] VIC 102
[07:33:29] [PASSED] VIC 106
[07:33:29] [PASSED] VIC 107
[07:33:29] === [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_valid ===
[07:33:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc
[07:33:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc
[07:33:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc
[07:33:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc
[07:33:29] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc
[07:33:29] === [PASSED] drm_test_connector_hdmi_compute_mode_clock ====
[07:33:29] == drm_hdmi_connector_get_broadcast_rgb_name (2 subtests) ==
[07:33:29] === drm_test_drm_hdmi_connector_get_broadcast_rgb_name  ====
[07:33:29] [PASSED] Automatic
[07:33:29] [PASSED] Full
[07:33:29] [PASSED] Limited 16:235
[07:33:29] === [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name ===
[07:33:29] [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid
[07:33:29] ==== [PASSED] drm_hdmi_connector_get_broadcast_rgb_name ====
[07:33:29] == drm_hdmi_connector_get_output_format_name (2 subtests) ==
[07:33:29] === drm_test_drm_hdmi_connector_get_output_format_name  ====
[07:33:29] [PASSED] RGB
[07:33:29] [PASSED] YUV 4:2:0
[07:33:29] [PASSED] YUV 4:2:2
[07:33:29] [PASSED] YUV 4:4:4
[07:33:29] === [PASSED] drm_test_drm_hdmi_connector_get_output_format_name ===
[07:33:29] [PASSED] drm_test_drm_hdmi_connector_get_output_format_name_invalid
[07:33:29] ==== [PASSED] drm_hdmi_connector_get_output_format_name ====
[07:33:29] ============= drm_damage_helper (21 subtests) ==============
[07:33:29] [PASSED] drm_test_damage_iter_no_damage
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_fractional_src
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_src_moved
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_not_visible
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_no_crtc
[07:33:29] [PASSED] drm_test_damage_iter_no_damage_no_fb
[07:33:29] [PASSED] drm_test_damage_iter_simple_damage
[07:33:29] [PASSED] drm_test_damage_iter_single_damage
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_intersect_src
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_outside_src
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_fractional_src
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_src_moved
[07:33:29] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved
[07:33:29] [PASSED] drm_test_damage_iter_damage
[07:33:29] [PASSED] drm_test_damage_iter_damage_one_intersect
[07:33:29] [PASSED] drm_test_damage_iter_damage_one_outside
[07:33:29] [PASSED] drm_test_damage_iter_damage_src_moved
[07:33:29] [PASSED] drm_test_damage_iter_damage_not_visible
[07:33:29] ================ [PASSED] drm_damage_helper ================
[07:33:29] ============== drm_dp_mst_helper (3 subtests) ==============
[07:33:29] ============== drm_test_dp_mst_calc_pbn_mode  ==============
[07:33:29] [PASSED] Clock 154000 BPP 30 DSC disabled
[07:33:29] [PASSED] Clock 234000 BPP 30 DSC disabled
[07:33:29] [PASSED] Clock 297000 BPP 24 DSC disabled
[07:33:29] [PASSED] Clock 332880 BPP 24 DSC enabled
[07:33:29] [PASSED] Clock 324540 BPP 24 DSC enabled
[07:33:29] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ==========
[07:33:29] ============== drm_test_dp_mst_calc_pbn_div  ===============
[07:33:29] [PASSED] Link rate 2000000 lane count 4
[07:33:29] [PASSED] Link rate 2000000 lane count 2
[07:33:29] [PASSED] Link rate 2000000 lane count 1
[07:33:29] [PASSED] Link rate 1350000 lane count 4
[07:33:29] [PASSED] Link rate 1350000 lane count 2
[07:33:29] [PASSED] Link rate 1350000 lane count 1
[07:33:29] [PASSED] Link rate 1000000 lane count 4
[07:33:29] [PASSED] Link rate 1000000 lane count 2
[07:33:29] [PASSED] Link rate 1000000 lane count 1
[07:33:29] [PASSED] Link rate 810000 lane count 4
[07:33:29] [PASSED] Link rate 810000 lane count 2
[07:33:29] [PASSED] Link rate 810000 lane count 1
[07:33:29] [PASSED] Link rate 540000 lane count 4
[07:33:29] [PASSED] Link rate 540000 lane count 2
[07:33:29] [PASSED] Link rate 540000 lane count 1
[07:33:29] [PASSED] Link rate 270000 lane count 4
[07:33:29] [PASSED] Link rate 270000 lane count 2
[07:33:29] [PASSED] Link rate 270000 lane count 1
[07:33:29] [PASSED] Link rate 162000 lane count 4
[07:33:29] [PASSED] Link rate 162000 lane count 2
[07:33:29] [PASSED] Link rate 162000 lane count 1
[07:33:29] ========== [PASSED] drm_test_dp_mst_calc_pbn_div ===========
[07:33:29] ========= drm_test_dp_mst_sideband_msg_req_decode  =========
[07:33:29] [PASSED] DP_ENUM_PATH_RESOURCES with port number
[07:33:29] [PASSED] DP_POWER_UP_PHY with port number
[07:33:29] [PASSED] DP_POWER_DOWN_PHY with port number
[07:33:29] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks
[07:33:29] [PASSED] DP_ALLOCATE_PAYLOAD with port number
[07:33:29] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI
[07:33:29] [PASSED] DP_ALLOCATE_PAYLOAD with PBN
[07:33:29] [PASSED] DP_QUERY_PAYLOAD with port number
[07:33:29] [PASSED] DP_QUERY_PAYLOAD with VCPI
[07:33:29] [PASSED] DP_REMOTE_DPCD_READ with port number
[07:33:29] [PASSED] DP_REMOTE_DPCD_READ with DPCD address
[07:33:29] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes
[07:33:29] [PASSED] DP_REMOTE_DPCD_WRITE with port number
[07:33:29] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address
[07:33:29] [PASSED] DP_REMOTE_DPCD_WRITE with data array
[07:33:29] [PASSED] DP_REMOTE_I2C_READ with port number
[07:33:29] [PASSED] DP_REMOTE_I2C_READ with I2C device ID
[07:33:29] [PASSED] DP_REMOTE_I2C_READ with transactions array
[07:33:29] [PASSED] DP_REMOTE_I2C_WRITE with port number
[07:33:29] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID
[07:33:29] [PASSED] DP_REMOTE_I2C_WRITE with data array
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior
[07:33:29] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior
[07:33:29] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode =====
[07:33:29] ================ [PASSED] drm_dp_mst_helper ================
[07:33:29] ================== drm_exec (7 subtests) ===================
[07:33:29] [PASSED] sanitycheck
[07:33:29] [PASSED] test_lock
[07:33:29] [PASSED] test_lock_unlock
[07:33:29] [PASSED] test_duplicates
[07:33:29] [PASSED] test_prepare
[07:33:29] [PASSED] test_prepare_array
[07:33:29] [PASSED] test_multiple_loops
[07:33:29] ==================== [PASSED] drm_exec =====================
[07:33:29] =========== drm_format_helper_test (17 subtests) ===========
[07:33:29] ============== drm_test_fb_xrgb8888_to_gray8  ==============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ==========
[07:33:29] ============= drm_test_fb_xrgb8888_to_rgb332  ==============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ==========
[07:33:29] ============= drm_test_fb_xrgb8888_to_rgb565  ==============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ==========
[07:33:29] ============ drm_test_fb_xrgb8888_to_xrgb1555  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 =========
[07:33:29] ============ drm_test_fb_xrgb8888_to_argb1555  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 =========
[07:33:29] ============ drm_test_fb_xrgb8888_to_rgba5551  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 =========
[07:33:29] ============= drm_test_fb_xrgb8888_to_rgb888  ==============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ==========
[07:33:29] ============= drm_test_fb_xrgb8888_to_bgr888  ==============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========= [PASSED] drm_test_fb_xrgb8888_to_bgr888 ==========
[07:33:29] ============ drm_test_fb_xrgb8888_to_argb8888  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 =========
[07:33:29] =========== drm_test_fb_xrgb8888_to_xrgb2101010  ===========
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 =======
[07:33:29] =========== drm_test_fb_xrgb8888_to_argb2101010  ===========
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 =======
[07:33:29] ============== drm_test_fb_xrgb8888_to_mono  ===============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ========== [PASSED] drm_test_fb_xrgb8888_to_mono ===========
[07:33:29] ==================== drm_test_fb_swab  =====================
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ================ [PASSED] drm_test_fb_swab =================
[07:33:29] ============ drm_test_fb_xrgb8888_to_xbgr8888  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_xbgr8888 =========
[07:33:29] ============ drm_test_fb_xrgb8888_to_abgr8888  =============
[07:33:29] [PASSED] single_pixel_source_buffer
[07:33:29] [PASSED] single_pixel_clip_rectangle
[07:33:29] [PASSED] well_known_colors
[07:33:29] [PASSED] destination_pitch
[07:33:29] ======== [PASSED] drm_test_fb_xrgb8888_to_abgr8888 =========
[07:33:29] ================= drm_test_fb_clip_offset  =================
[07:33:29] [PASSED] pass through
[07:33:29] [PASSED] horizontal offset
[07:33:29] [PASSED] vertical offset
[07:33:29] [PASSED] horizontal and vertical offset
[07:33:29] [PASSED] horizontal offset (custom pitch)
[07:33:29] [PASSED] vertical offset (custom pitch)
[07:33:29] [PASSED] horizontal and vertical offset (custom pitch)
[07:33:29] ============= [PASSED] drm_test_fb_clip_offset =============
[07:33:29] =================== drm_test_fb_memcpy  ====================
[07:33:29] [PASSED] single_pixel_source_buffer: XR24 little-endian (0x34325258)
[07:33:29] [PASSED] single_pixel_source_buffer: XRA8 little-endian (0x38415258)
[07:33:29] [PASSED] single_pixel_source_buffer: YU24 little-endian (0x34325559)
[07:33:29] [PASSED] single_pixel_clip_rectangle: XB24 little-endian (0x34324258)
[07:33:29] [PASSED] single_pixel_clip_rectangle: XRA8 little-endian (0x38415258)
[07:33:29] [PASSED] single_pixel_clip_rectangle: YU24 little-endian (0x34325559)
[07:33:29] [PASSED] well_known_colors: XB24 little-endian (0x34324258)
[07:33:29] [PASSED] well_known_colors: XRA8 little-endian (0x38415258)
[07:33:29] [PASSED] well_known_colors: YU24 little-endian (0x34325559)
[07:33:29] [PASSED] destination_pitch: XB24 little-endian (0x34324258)
[07:33:29] [PASSED] destination_pitch: XRA8 little-endian (0x38415258)
[07:33:29] [PASSED] destination_pitch: YU24 little-endian (0x34325559)
[07:33:29] =============== [PASSED] drm_test_fb_memcpy ================
[07:33:29] ============= [PASSED] drm_format_helper_test ==============
[07:33:29] ================= drm_format (18 subtests) =================
[07:33:29] [PASSED] drm_test_format_block_width_invalid
[07:33:29] [PASSED] drm_test_format_block_width_one_plane
[07:33:29] [PASSED] drm_test_format_block_width_two_plane
[07:33:29] [PASSED] drm_test_format_block_width_three_plane
[07:33:29] [PASSED] drm_test_format_block_width_tiled
[07:33:29] [PASSED] drm_test_format_block_height_invalid
[07:33:29] [PASSED] drm_test_format_block_height_one_plane
[07:33:29] [PASSED] drm_test_format_block_height_two_plane
[07:33:29] [PASSED] drm_test_format_block_height_three_plane
[07:33:29] [PASSED] drm_test_format_block_height_tiled
[07:33:29] [PASSED] drm_test_format_min_pitch_invalid
[07:33:29] [PASSED] drm_test_format_min_pitch_one_plane_8bpp
[07:33:29] [PASSED] drm_test_format_min_pitch_one_plane_16bpp
[07:33:29] [PASSED] drm_test_format_min_pitch_one_plane_24bpp
[07:33:29] [PASSED] drm_test_format_min_pitch_one_plane_32bpp
[07:33:29] [PASSED] drm_test_format_min_pitch_two_plane
[07:33:29] [PASSED] drm_test_format_min_pitch_three_plane_8bpp
[07:33:29] [PASSED] drm_test_format_min_pitch_tiled
[07:33:29] =================== [PASSED] drm_format ====================
[07:33:29] ============== drm_framebuffer (10 subtests) ===============
[07:33:29] ========== drm_test_framebuffer_check_src_coords  ==========
[07:33:29] [PASSED] Success: source fits into fb
[07:33:29] [PASSED] Fail: overflowing fb with x-axis coordinate
[07:33:29] [PASSED] Fail: overflowing fb with y-axis coordinate
[07:33:29] [PASSED] Fail: overflowing fb with source width
[07:33:29] [PASSED] Fail: overflowing fb with source height
[07:33:29] ====== [PASSED] drm_test_framebuffer_check_src_coords ======
[07:33:29] [PASSED] drm_test_framebuffer_cleanup
[07:33:29] =============== drm_test_framebuffer_create  ===============
[07:33:29] [PASSED] ABGR8888 normal sizes
[07:33:29] [PASSED] ABGR8888 max sizes
[07:33:29] [PASSED] ABGR8888 pitch greater than min required
[07:33:29] [PASSED] ABGR8888 pitch less than min required
[07:33:29] [PASSED] ABGR8888 Invalid width
[07:33:29] [PASSED] ABGR8888 Invalid buffer handle
[07:33:29] [PASSED] No pixel format
[07:33:29] [PASSED] ABGR8888 Width 0
[07:33:29] [PASSED] ABGR8888 Height 0
[07:33:29] [PASSED] ABGR8888 Out of bound height * pitch combination
[07:33:29] [PASSED] ABGR8888 Large buffer offset
[07:33:29] [PASSED] ABGR8888 Buffer offset for inexistent plane
[07:33:29] [PASSED] ABGR8888 Invalid flag
[07:33:29] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers
[07:33:29] [PASSED] ABGR8888 Valid buffer modifier
[07:33:29] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
[07:33:29] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] NV12 Normal sizes
[07:33:29] [PASSED] NV12 Max sizes
[07:33:29] [PASSED] NV12 Invalid pitch
[07:33:29] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag
[07:33:29] [PASSED] NV12 different  modifier per-plane
[07:33:29] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
[07:33:29] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] NV12 Modifier for inexistent plane
[07:33:29] [PASSED] NV12 Handle for inexistent plane
[07:33:29] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier
[07:33:29] [PASSED] YVU420 Normal sizes
[07:33:29] [PASSED] YVU420 Max sizes
[07:33:29] [PASSED] YVU420 Invalid pitch
[07:33:29] [PASSED] YVU420 Different pitches
[07:33:29] [PASSED] YVU420 Different buffer offsets/pitches
[07:33:29] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS
[07:33:29] [PASSED] YVU420 Valid modifier
[07:33:29] [PASSED] YVU420 Different modifiers per plane
[07:33:29] [PASSED] YVU420 Modifier for inexistent plane
[07:33:29] [PASSED] YUV420_10BIT Invalid modifier(DRM_FORMAT_MOD_LINEAR)
[07:33:29] [PASSED] X0L2 Normal sizes
[07:33:29] [PASSED] X0L2 Max sizes
[07:33:29] [PASSED] X0L2 Invalid pitch
[07:33:29] [PASSED] X0L2 Pitch greater than minimum required
[07:33:29] [PASSED] X0L2 Handle for inexistent plane
[07:33:29] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set
[07:33:29] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set
[07:33:29] [PASSED] X0L2 Valid modifier
[07:33:29] [PASSED] X0L2 Modifier for inexistent plane
[07:33:29] =========== [PASSED] drm_test_framebuffer_create ===========
[07:33:29] [PASSED] drm_test_framebuffer_free
[07:33:29] [PASSED] drm_test_framebuffer_init
[07:33:29] [PASSED] drm_test_framebuffer_init_bad_format
[07:33:29] [PASSED] drm_test_framebuffer_init_dev_mismatch
[07:33:29] [PASSED] drm_test_framebuffer_lookup
[07:33:29] [PASSED] drm_test_framebuffer_lookup_inexistent
[07:33:29] [PASSED] drm_test_framebuffer_modifiers_not_supported
[07:33:29] ================= [PASSED] drm_framebuffer =================
[07:33:29] ================ drm_gem_shmem (8 subtests) ================
[07:33:29] [PASSED] drm_gem_shmem_test_obj_create
[07:33:29] [PASSED] drm_gem_shmem_test_obj_create_private
[07:33:29] [PASSED] drm_gem_shmem_test_pin_pages
[07:33:29] [PASSED] drm_gem_shmem_test_vmap
[07:33:29] [PASSED] drm_gem_shmem_test_get_pages_sgt
[07:33:29] [PASSED] drm_gem_shmem_test_get_sg_table
[07:33:29] [PASSED] drm_gem_shmem_test_madvise
[07:33:29] [PASSED] drm_gem_shmem_test_purge
[07:33:29] ================== [PASSED] drm_gem_shmem ==================
[07:33:29] === drm_atomic_helper_connector_hdmi_check (27 subtests) ===
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode_vic_1
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode_vic_1
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode_vic_1
[07:33:29] ====== drm_test_check_broadcast_rgb_cea_mode_yuv420  =======
[07:33:29] [PASSED] Automatic
[07:33:29] [PASSED] Full
[07:33:29] [PASSED] Limited 16:235
[07:33:29] == [PASSED] drm_test_check_broadcast_rgb_cea_mode_yuv420 ===
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_changed
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_not_changed
[07:33:29] [PASSED] drm_test_check_disable_connector
[07:33:29] [PASSED] drm_test_check_hdmi_funcs_reject_rate
[07:33:29] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_rgb
[07:33:29] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_yuv420
[07:33:29] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv422
[07:33:29] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv420
[07:33:29] [PASSED] drm_test_check_driver_unsupported_fallback_yuv420
[07:33:29] [PASSED] drm_test_check_output_bpc_crtc_mode_changed
[07:33:29] [PASSED] drm_test_check_output_bpc_crtc_mode_not_changed
[07:33:29] [PASSED] drm_test_check_output_bpc_dvi
[07:33:29] [PASSED] drm_test_check_output_bpc_format_vic_1
[07:33:29] [PASSED] drm_test_check_output_bpc_format_display_8bpc_only
[07:33:29] [PASSED] drm_test_check_output_bpc_format_display_rgb_only
[07:33:29] [PASSED] drm_test_check_output_bpc_format_driver_8bpc_only
[07:33:29] [PASSED] drm_test_check_output_bpc_format_driver_rgb_only
[07:33:29] [PASSED] drm_test_check_tmds_char_rate_rgb_8bpc
[07:33:29] [PASSED] drm_test_check_tmds_char_rate_rgb_10bpc
[07:33:29] [PASSED] drm_test_check_tmds_char_rate_rgb_12bpc
[07:33:29] ===== [PASSED] drm_atomic_helper_connector_hdmi_check ======
[07:33:29] === drm_atomic_helper_connector_hdmi_reset (6 subtests) ====
[07:33:29] [PASSED] drm_test_check_broadcast_rgb_value
[07:33:29] [PASSED] drm_test_check_bpc_8_value
[07:33:29] [PASSED] drm_test_check_bpc_10_value
[07:33:29] [PASSED] drm_test_check_bpc_12_value
[07:33:29] [PASSED] drm_test_check_format_value
[07:33:29] [PASSED] drm_test_check_tmds_char_value
[07:33:29] ===== [PASSED] drm_atomic_helper_connector_hdmi_reset ======
[07:33:29] = drm_atomic_helper_connector_hdmi_mode_valid (4 subtests) =
[07:33:29] [PASSED] drm_test_check_mode_valid
[07:33:29] [PASSED] drm_test_check_mode_valid_reject
[07:33:29] [PASSED] drm_test_check_mode_valid_reject_rate
[07:33:29] [PASSED] drm_test_check_mode_valid_reject_max_clock
[07:33:29] === [PASSED] drm_atomic_helper_connector_hdmi_mode_valid ===
[07:33:29] ================= drm_managed (2 subtests) =================
[07:33:29] [PASSED] drm_test_managed_release_action
[07:33:29] [PASSED] drm_test_managed_run_action
[07:33:29] =================== [PASSED] drm_managed ===================
[07:33:29] =================== drm_mm (6 subtests) ====================
[07:33:29] [PASSED] drm_test_mm_init
[07:33:29] [PASSED] drm_test_mm_debug
[07:33:29] [PASSED] drm_test_mm_align32
[07:33:29] [PASSED] drm_test_mm_align64
[07:33:29] [PASSED] drm_test_mm_lowest
[07:33:29] [PASSED] drm_test_mm_highest
[07:33:29] ===================== [PASSED] drm_mm ======================
[07:33:29] ============= drm_modes_analog_tv (5 subtests) =============
[07:33:29] [PASSED] drm_test_modes_analog_tv_mono_576i
[07:33:29] [PASSED] drm_test_modes_analog_tv_ntsc_480i
[07:33:29] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined
[07:33:29] [PASSED] drm_test_modes_analog_tv_pal_576i
[07:33:29] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined
[07:33:29] =============== [PASSED] drm_modes_analog_tv ===============
[07:33:29] ============== drm_plane_helper (2 subtests) ===============
[07:33:29] =============== drm_test_check_plane_state  ================
[07:33:29] [PASSED] clipping_simple
[07:33:29] [PASSED] clipping_rotate_reflect
[07:33:29] [PASSED] positioning_simple
[07:33:29] [PASSED] upscaling
[07:33:29] [PASSED] downscaling
[07:33:29] [PASSED] rounding1
[07:33:29] [PASSED] rounding2
[07:33:29] [PASSED] rounding3
[07:33:29] [PASSED] rounding4
[07:33:29] =========== [PASSED] drm_test_check_plane_state ============
[07:33:29] =========== drm_test_check_invalid_plane_state  ============
[07:33:29] [PASSED] positioning_invalid
[07:33:29] [PASSED] upscaling_invalid
[07:33:29] [PASSED] downscaling_invalid
[07:33:29] ======= [PASSED] drm_test_check_invalid_plane_state ========
[07:33:29] ================ [PASSED] drm_plane_helper =================
[07:33:29] ====== drm_connector_helper_tv_get_modes (1 subtest) =======
[07:33:29] ====== drm_test_connector_helper_tv_get_modes_check  =======
[07:33:29] [PASSED] None
[07:33:29] [PASSED] PAL
[07:33:29] [PASSED] NTSC
[07:33:29] [PASSED] Both, NTSC Default
[07:33:29] [PASSED] Both, PAL Default
[07:33:29] [PASSED] Both, NTSC Default, with PAL on command-line
[07:33:29] [PASSED] Both, PAL Default, with NTSC on command-line
[07:33:29] == [PASSED] drm_test_connector_helper_tv_get_modes_check ===
[07:33:29] ======== [PASSED] drm_connector_helper_tv_get_modes ========
[07:33:29] ================== drm_rect (9 subtests) ===================
[07:33:29] [PASSED] drm_test_rect_clip_scaled_div_by_zero
[07:33:29] [PASSED] drm_test_rect_clip_scaled_not_clipped
[07:33:29] [PASSED] drm_test_rect_clip_scaled_clipped
[07:33:29] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned
[07:33:29] ================= drm_test_rect_intersect  =================
[07:33:29] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0
[07:33:29] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1
[07:33:29] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0
[07:33:29] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1
[07:33:29] [PASSED] right x left: 2x1+0+0 x 3x1+1+0
[07:33:29] [PASSED] left x right: 3x1+1+0 x 2x1+0+0
[07:33:29] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1
[07:33:29] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0
[07:33:29] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1
[07:33:29] [PASSED] touching side: 1x1+0+0 x 1x1+1+0
[07:33:29] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0
[07:33:29] [PASSED] inside another: 2x2+0+0 x 1x1+1+1
[07:33:29] [PASSED] far away: 1x1+0+0 x 1x1+3+6
[07:33:29] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10
[07:33:29] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10
[07:33:29] ============= [PASSED] drm_test_rect_intersect =============
[07:33:29] ================ drm_test_rect_calc_hscale  ================
[07:33:29] [PASSED] normal use
[07:33:29] [PASSED] out of max range
[07:33:29] [PASSED] out of min range
[07:33:29] [PASSED] zero dst
[07:33:29] [PASSED] negative src
[07:33:29] [PASSED] negative dst
[07:33:29] ============ [PASSED] drm_test_rect_calc_hscale ============
[07:33:29] ================ drm_test_rect_calc_vscale  ================
[07:33:29] [PASSED] normal use
[07:33:29] [PASSED] out of max range
[07:33:29] [PASSED] out of min range
[07:33:29] [PASSED] zero dst
[07:33:29] [PASSED] negative src
[07:33:29] [PASSED] negative dst
[07:33:29] ============ [PASSED] drm_test_rect_calc_vscale ============
[07:33:29] ================== drm_test_rect_rotate  ===================
[07:33:29] [PASSED] reflect-x
[07:33:29] [PASSED] reflect-y
[07:33:29] [PASSED] rotate-0
[07:33:29] [PASSED] rotate-90
[07:33:29] [PASSED] rotate-180
[07:33:29] [PASSED] rotate-270
stty: 'standard input': Inappropriate ioctl for device
[07:33:29] ============== [PASSED] drm_test_rect_rotate ===============
[07:33:29] ================ drm_test_rect_rotate_inv  =================
[07:33:29] [PASSED] reflect-x
[07:33:29] [PASSED] reflect-y
[07:33:29] [PASSED] rotate-0
[07:33:29] [PASSED] rotate-90
[07:33:29] [PASSED] rotate-180
[07:33:29] [PASSED] rotate-270
[07:33:29] ============ [PASSED] drm_test_rect_rotate_inv =============
[07:33:29] ==================== [PASSED] drm_rect =====================
[07:33:29] ============ drm_sysfb_modeset_test (1 subtest) ============
[07:33:29] ============ drm_test_sysfb_build_fourcc_list  =============
[07:33:29] [PASSED] no native formats
[07:33:29] [PASSED] XRGB8888 as native format
[07:33:29] [PASSED] remove duplicates
[07:33:29] [PASSED] convert alpha formats
[07:33:29] [PASSED] random formats
[07:33:29] ======== [PASSED] drm_test_sysfb_build_fourcc_list =========
[07:33:29] ============= [PASSED] drm_sysfb_modeset_test ==============
[07:33:29] ============================================================
[07:33:29] Testing complete. Ran 616 tests: passed: 616
[07:33:29] Elapsed time: 24.634s total, 1.748s configuring, 22.720s building, 0.143s running

+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/ttm/tests/.kunitconfig
[07:33:29] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[07:33:31] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[07:33:39] Starting KUnit Kernel (1/1)...
[07:33:39] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[07:33:39] ================= ttm_device (5 subtests) ==================
[07:33:39] [PASSED] ttm_device_init_basic
[07:33:39] [PASSED] ttm_device_init_multiple
[07:33:39] [PASSED] ttm_device_fini_basic
[07:33:39] [PASSED] ttm_device_init_no_vma_man
[07:33:39] ================== ttm_device_init_pools  ==================
[07:33:39] [PASSED] No DMA allocations, no DMA32 required
[07:33:39] [PASSED] DMA allocations, DMA32 required
[07:33:39] [PASSED] No DMA allocations, DMA32 required
[07:33:39] [PASSED] DMA allocations, no DMA32 required
[07:33:39] ============== [PASSED] ttm_device_init_pools ==============
[07:33:39] =================== [PASSED] ttm_device ====================
[07:33:39] ================== ttm_pool (8 subtests) ===================
[07:33:39] ================== ttm_pool_alloc_basic  ===================
[07:33:39] [PASSED] One page
[07:33:39] [PASSED] More than one page
[07:33:39] [PASSED] Above the allocation limit
[07:33:39] [PASSED] One page, with coherent DMA mappings enabled
[07:33:39] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[07:33:39] ============== [PASSED] ttm_pool_alloc_basic ===============
[07:33:39] ============== ttm_pool_alloc_basic_dma_addr  ==============
[07:33:39] [PASSED] One page
[07:33:39] [PASSED] More than one page
[07:33:39] [PASSED] Above the allocation limit
[07:33:39] [PASSED] One page, with coherent DMA mappings enabled
[07:33:39] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[07:33:39] ========== [PASSED] ttm_pool_alloc_basic_dma_addr ==========
[07:33:39] [PASSED] ttm_pool_alloc_order_caching_match
[07:33:39] [PASSED] ttm_pool_alloc_caching_mismatch
[07:33:39] [PASSED] ttm_pool_alloc_order_mismatch
[07:33:39] [PASSED] ttm_pool_free_dma_alloc
[07:33:39] [PASSED] ttm_pool_free_no_dma_alloc
[07:33:39] [PASSED] ttm_pool_fini_basic
[07:33:39] ==================== [PASSED] ttm_pool =====================
[07:33:39] ================ ttm_resource (8 subtests) =================
[07:33:39] ================= ttm_resource_init_basic  =================
[07:33:39] [PASSED] Init resource in TTM_PL_SYSTEM
[07:33:39] [PASSED] Init resource in TTM_PL_VRAM
[07:33:39] [PASSED] Init resource in a private placement
[07:33:39] [PASSED] Init resource in TTM_PL_SYSTEM, set placement flags
[07:33:39] ============= [PASSED] ttm_resource_init_basic =============
[07:33:39] [PASSED] ttm_resource_init_pinned
[07:33:39] [PASSED] ttm_resource_fini_basic
[07:33:39] [PASSED] ttm_resource_manager_init_basic
[07:33:39] [PASSED] ttm_resource_manager_usage_basic
[07:33:39] [PASSED] ttm_resource_manager_set_used_basic
[07:33:39] [PASSED] ttm_sys_man_alloc_basic
[07:33:39] [PASSED] ttm_sys_man_free_basic
[07:33:39] ================== [PASSED] ttm_resource ===================
[07:33:39] =================== ttm_tt (15 subtests) ===================
[07:33:39] ==================== ttm_tt_init_basic  ====================
[07:33:39] [PASSED] Page-aligned size
[07:33:39] [PASSED] Extra pages requested
[07:33:39] ================ [PASSED] ttm_tt_init_basic ================
[07:33:39] [PASSED] ttm_tt_init_misaligned
[07:33:39] [PASSED] ttm_tt_fini_basic
[07:33:39] [PASSED] ttm_tt_fini_sg
[07:33:39] [PASSED] ttm_tt_fini_shmem
[07:33:39] [PASSED] ttm_tt_create_basic
[07:33:39] [PASSED] ttm_tt_create_invalid_bo_type
[07:33:39] [PASSED] ttm_tt_create_ttm_exists
[07:33:39] [PASSED] ttm_tt_create_failed
[07:33:39] [PASSED] ttm_tt_destroy_basic
[07:33:39] [PASSED] ttm_tt_populate_null_ttm
[07:33:39] [PASSED] ttm_tt_populate_populated_ttm
[07:33:39] [PASSED] ttm_tt_unpopulate_basic
[07:33:39] [PASSED] ttm_tt_unpopulate_empty_ttm
[07:33:39] [PASSED] ttm_tt_swapin_basic
[07:33:39] ===================== [PASSED] ttm_tt ======================
[07:33:39] =================== ttm_bo (14 subtests) ===================
[07:33:39] =========== ttm_bo_reserve_optimistic_no_ticket  ===========
[07:33:39] [PASSED] Cannot be interrupted and sleeps
[07:33:39] [PASSED] Cannot be interrupted, locks straight away
[07:33:39] [PASSED] Can be interrupted, sleeps
[07:33:39] ======= [PASSED] ttm_bo_reserve_optimistic_no_ticket =======
[07:33:39] [PASSED] ttm_bo_reserve_locked_no_sleep
[07:33:39] [PASSED] ttm_bo_reserve_no_wait_ticket
[07:33:39] [PASSED] ttm_bo_reserve_double_resv
[07:33:39] [PASSED] ttm_bo_reserve_interrupted
[07:33:39] [PASSED] ttm_bo_reserve_deadlock
[07:33:39] [PASSED] ttm_bo_unreserve_basic
[07:33:39] [PASSED] ttm_bo_unreserve_pinned
[07:33:39] [PASSED] ttm_bo_unreserve_bulk
[07:33:39] [PASSED] ttm_bo_put_basic
[07:33:39] [PASSED] ttm_bo_put_shared_resv
[07:33:39] [PASSED] ttm_bo_pin_basic
[07:33:39] [PASSED] ttm_bo_pin_unpin_resource
[07:33:39] [PASSED] ttm_bo_multiple_pin_one_unpin
[07:33:39] ===================== [PASSED] ttm_bo ======================
[07:33:39] ============== ttm_bo_validate (21 subtests) ===============
[07:33:39] ============== ttm_bo_init_reserved_sys_man  ===============
[07:33:39] [PASSED] Buffer object for userspace
[07:33:39] [PASSED] Kernel buffer object
[07:33:39] [PASSED] Shared buffer object
[07:33:39] ========== [PASSED] ttm_bo_init_reserved_sys_man ===========
[07:33:39] ============== ttm_bo_init_reserved_mock_man  ==============
[07:33:39] [PASSED] Buffer object for userspace
[07:33:39] [PASSED] Kernel buffer object
[07:33:39] [PASSED] Shared buffer object
[07:33:39] ========== [PASSED] ttm_bo_init_reserved_mock_man ==========
[07:33:39] [PASSED] ttm_bo_init_reserved_resv
[07:33:39] ================== ttm_bo_validate_basic  ==================
[07:33:39] [PASSED] Buffer object for userspace
[07:33:39] [PASSED] Kernel buffer object
[07:33:39] [PASSED] Shared buffer object
[07:33:39] ============== [PASSED] ttm_bo_validate_basic ==============
[07:33:39] [PASSED] ttm_bo_validate_invalid_placement
[07:33:39] ============= ttm_bo_validate_same_placement  ==============
[07:33:39] [PASSED] System manager
[07:33:39] [PASSED] VRAM manager
[07:33:39] ========= [PASSED] ttm_bo_validate_same_placement ==========
[07:33:39] [PASSED] ttm_bo_validate_failed_alloc
[07:33:39] [PASSED] ttm_bo_validate_pinned
[07:33:39] [PASSED] ttm_bo_validate_busy_placement
[07:33:39] ================ ttm_bo_validate_multihop  =================
[07:33:39] [PASSED] Buffer object for userspace
[07:33:39] [PASSED] Kernel buffer object
[07:33:39] [PASSED] Shared buffer object
[07:33:39] ============ [PASSED] ttm_bo_validate_multihop =============
[07:33:39] ========== ttm_bo_validate_no_placement_signaled  ==========
[07:33:39] [PASSED] Buffer object in system domain, no page vector
[07:33:39] [PASSED] Buffer object in system domain with an existing page vector
[07:33:39] ====== [PASSED] ttm_bo_validate_no_placement_signaled ======
[07:33:39] ======== ttm_bo_validate_no_placement_not_signaled  ========
[07:33:39] [PASSED] Buffer object for userspace
[07:33:39] [PASSED] Kernel buffer object
[07:33:39] [PASSED] Shared buffer object
[07:33:39] ==== [PASSED] ttm_bo_validate_no_placement_not_signaled ====
[07:33:39] [PASSED] ttm_bo_validate_move_fence_signaled
[07:33:39] ========= ttm_bo_validate_move_fence_not_signaled  =========
[07:33:39] [PASSED] Waits for GPU
[07:33:39] [PASSED] Tries to lock straight away
[07:33:39] ===== [PASSED] ttm_bo_validate_move_fence_not_signaled =====
[07:33:39] [PASSED] ttm_bo_validate_happy_evict
[07:33:39] [PASSED] ttm_bo_validate_all_pinned_evict
[07:33:39] [PASSED] ttm_bo_validate_allowed_only_evict
[07:33:39] [PASSED] ttm_bo_validate_deleted_evict
[07:33:39] [PASSED] ttm_bo_validate_busy_domain_evict
[07:33:39] [PASSED] ttm_bo_validate_evict_gutting
[07:33:39] [PASSED] ttm_bo_validate_recrusive_evict
stty: 'standard input': Inappropriate ioctl for device
[07:33:39] ================= [PASSED] ttm_bo_validate =================
[07:33:39] ============================================================
[07:33:39] Testing complete. Ran 101 tests: passed: 101
[07:33:39] Elapsed time: 9.834s total, 1.673s configuring, 7.945s building, 0.187s running

+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel

✓ Xe.CI.BAT: success for drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

== Series Details ==

Series: drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds
URL   : https://patchwork.freedesktop.org/series/154504/
State : success

== Summary ==

CI Bug Log - changes from xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b_BAT -> xe-pw-154504v1_BAT
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts

Known issues
------------

  Here are the changes found in xe-pw-154504v1_BAT that come from known issues:

### IGT changes ###

#### Possible fixes ####

  * igt@xe_vm@bind-execqueues-independent:
    - {bat-ptl-2}:        [FAIL][1] ([Intel XE#5783]) -> [PASS][2]
   [1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/bat-ptl-2/igt@xe_vm@bind-execqueues-independent.html
   [2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/bat-ptl-2/igt@xe_vm@bind-execqueues-independent.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [Intel XE#5783]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5783


Build changes
-------------

  * Linux: xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b -> xe-pw-154504v1

  IGT_8539: 8539
  xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b: 36a8f6b405f4a0def4462366cd17992897e1362b
  xe-pw-154504v1: 154504v1

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/index.html

[-- Attachment #2: Type: text/html, Size: 2204 bytes --]

✗ Xe.CI.Full: failure for drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 49343 bytes --]

== Series Details ==

Series: drm/xe/sriov: Don't migrate dmabuf BO to System RAM if P2P check succeeds
URL   : https://patchwork.freedesktop.org/series/154504/
State : failure

== Summary ==

CI Bug Log - changes from xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b_FULL -> xe-pw-154504v1_FULL
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with xe-pw-154504v1_FULL absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in xe-pw-154504v1_FULL, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (4 -> 4)
------------------------------

  No changes in participating hosts

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in xe-pw-154504v1_FULL:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-d-dp-4:
    - shard-dg2-set2:     NOTRUN -> [INCOMPLETE][1]
   [1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-433/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-d-dp-4.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a1:
    - shard-adlp:         [PASS][2] -> [FAIL][3] +1 other test fail
   [2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a1.html
   [3]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-3/igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a1.html

  * igt@xe_fault_injection@probe-fail-guc-xe_guc_ct_send_recv:
    - shard-dg2-set2:     NOTRUN -> [ABORT][4]
   [4]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_fault_injection@probe-fail-guc-xe_guc_ct_send_recv.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@xe_fault_injection@inject-fault-probe-function-guc_wait_ucode}:
    - shard-bmg:          NOTRUN -> [FAIL][5]
   [5]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@xe_fault_injection@inject-fault-probe-function-guc_wait_ucode.html
    - shard-dg2-set2:     NOTRUN -> [FAIL][6]
   [6]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@xe_fault_injection@inject-fault-probe-function-guc_wait_ucode.html

  
Known issues
------------

  Here are the changes found in xe-pw-154504v1_FULL that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_big_fb@x-tiled-32bpp-rotate-90:
    - shard-bmg:          NOTRUN -> [SKIP][7] ([Intel XE#2327])
   [7]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0:
    - shard-dg2-set2:     NOTRUN -> [SKIP][8] ([Intel XE#1124]) +5 other tests skip
   [8]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
    - shard-bmg:          NOTRUN -> [SKIP][9] ([Intel XE#1124]) +1 other test skip
   [9]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html

  * igt@kms_bw@connected-linear-tiling-4-displays-3840x2160p:
    - shard-dg2-set2:     NOTRUN -> [SKIP][10] ([Intel XE#2191])
   [10]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_bw@connected-linear-tiling-4-displays-3840x2160p.html

  * igt@kms_ccs@ccs-on-another-bo-y-tiled-gen12-rc-ccs-cc@pipe-d-dp-4:
    - shard-dg2-set2:     NOTRUN -> [SKIP][11] ([Intel XE#455] / [Intel XE#787]) +33 other tests skip
   [11]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_ccs@ccs-on-another-bo-y-tiled-gen12-rc-ccs-cc@pipe-d-dp-4.html

  * igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-ccs:
    - shard-bmg:          NOTRUN -> [SKIP][12] ([Intel XE#2887]) +4 other tests skip
   [12]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-ccs.html

  * igt@kms_ccs@crc-sprite-planes-basic-y-tiled-gen12-mc-ccs@pipe-b-hdmi-a-6:
    - shard-dg2-set2:     NOTRUN -> [SKIP][13] ([Intel XE#787]) +195 other tests skip
   [13]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_ccs@crc-sprite-planes-basic-y-tiled-gen12-mc-ccs@pipe-b-hdmi-a-6.html

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-mc-ccs:
    - shard-dg2-set2:     NOTRUN -> [INCOMPLETE][14] ([Intel XE#1727] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4345] / [Intel XE#4522])
   [14]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-435/igt@kms_ccs@random-ccs-data-4-tiled-dg2-mc-ccs.html

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-mc-ccs@pipe-a-hdmi-a-6:
    - shard-dg2-set2:     [PASS][15] -> [INCOMPLETE][16] ([Intel XE#1727] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4522])
   [15]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-466/igt@kms_ccs@random-ccs-data-4-tiled-dg2-mc-ccs@pipe-a-hdmi-a-6.html
   [16]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-435/igt@kms_ccs@random-ccs-data-4-tiled-dg2-mc-ccs@pipe-a-hdmi-a-6.html

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs:
    - shard-dg2-set2:     [PASS][17] -> [INCOMPLETE][18] ([Intel XE#1727] / [Intel XE#2705] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4345] / [Intel XE#4522])
   [17]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-435/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs.html
   [18]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs.html

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-d-hdmi-a-6:
    - shard-dg2-set2:     NOTRUN -> [DMESG-WARN][19] ([Intel XE#1727] / [Intel XE#3113])
   [19]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-433/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-d-hdmi-a-6.html

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs@pipe-c-dp-4:
    - shard-dg2-set2:     [PASS][20] -> [INCOMPLETE][21] ([Intel XE#1727] / [Intel XE#2705] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4522])
   [20]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-435/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs@pipe-c-dp-4.html
   [21]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs@pipe-c-dp-4.html

  * igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs:
    - shard-dg2-set2:     NOTRUN -> [SKIP][22] ([Intel XE#2907]) +3 other tests skip
   [22]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs.html

  * igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs@pipe-c-dp-2:
    - shard-bmg:          NOTRUN -> [SKIP][23] ([Intel XE#2652] / [Intel XE#787]) +17 other tests skip
   [23]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs@pipe-c-dp-2.html

  * igt@kms_chamelium_color@ctm-green-to-red:
    - shard-bmg:          NOTRUN -> [SKIP][24] ([Intel XE#2325])
   [24]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_chamelium_color@ctm-green-to-red.html
    - shard-dg2-set2:     NOTRUN -> [SKIP][25] ([Intel XE#306])
   [25]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_chamelium_color@ctm-green-to-red.html

  * igt@kms_chamelium_frames@hdmi-aspect-ratio:
    - shard-dg2-set2:     NOTRUN -> [SKIP][26] ([Intel XE#373]) +4 other tests skip
   [26]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_chamelium_frames@hdmi-aspect-ratio.html

  * igt@kms_chamelium_hpd@dp-hpd-storm-disable:
    - shard-bmg:          NOTRUN -> [SKIP][27] ([Intel XE#2252]) +1 other test skip
   [27]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_chamelium_hpd@dp-hpd-storm-disable.html

  * igt@kms_content_protection@dp-mst-type-0:
    - shard-dg2-set2:     NOTRUN -> [SKIP][28] ([Intel XE#307])
   [28]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_content_protection@dp-mst-type-0.html

  * igt@kms_content_protection@lic-type-0@pipe-a-dp-4:
    - shard-dg2-set2:     NOTRUN -> [FAIL][29] ([Intel XE#3304])
   [29]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_content_protection@lic-type-0@pipe-a-dp-4.html

  * igt@kms_content_protection@uevent@pipe-a-dp-2:
    - shard-dg2-set2:     NOTRUN -> [FAIL][30] ([Intel XE#1188])
   [30]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@kms_content_protection@uevent@pipe-a-dp-2.html

  * igt@kms_cursor_crc@cursor-offscreen-128x42:
    - shard-bmg:          NOTRUN -> [SKIP][31] ([Intel XE#2320]) +1 other test skip
   [31]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_cursor_crc@cursor-offscreen-128x42.html

  * igt@kms_cursor_crc@cursor-rapid-movement-512x512:
    - shard-dg2-set2:     NOTRUN -> [SKIP][32] ([Intel XE#308])
   [32]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_cursor_crc@cursor-rapid-movement-512x512.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic:
    - shard-bmg:          [PASS][33] -> [FAIL][34] ([Intel XE#1475])
   [33]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-2/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
   [34]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-1/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html

  * igt@kms_dirtyfb@fbc-dirtyfb-ioctl:
    - shard-bmg:          NOTRUN -> [SKIP][35] ([Intel XE#5428])
   [35]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_dirtyfb@fbc-dirtyfb-ioctl.html

  * igt@kms_dp_link_training@uhbr-mst:
    - shard-bmg:          NOTRUN -> [SKIP][36] ([Intel XE#4354])
   [36]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_dp_link_training@uhbr-mst.html
    - shard-dg2-set2:     NOTRUN -> [SKIP][37] ([Intel XE#4356])
   [37]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_dp_link_training@uhbr-mst.html

  * igt@kms_dsc@dsc-with-output-formats-with-bpc:
    - shard-dg2-set2:     NOTRUN -> [SKIP][38] ([Intel XE#455]) +9 other tests skip
   [38]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@kms_dsc@dsc-with-output-formats-with-bpc.html

  * igt@kms_feature_discovery@display-2x:
    - shard-bmg:          NOTRUN -> [SKIP][39] ([Intel XE#2373])
   [39]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_feature_discovery@display-2x.html

  * igt@kms_flip@2x-flip-vs-suspend-interruptible:
    - shard-bmg:          [PASS][40] -> [SKIP][41] ([Intel XE#2316])
   [40]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-3/igt@kms_flip@2x-flip-vs-suspend-interruptible.html
   [41]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_flip@2x-flip-vs-suspend-interruptible.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
    - shard-lnl:          [PASS][42] -> [FAIL][43] ([Intel XE#301])
   [42]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-lnl-3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
   [43]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-lnl-1/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html

  * igt@kms_flip@flip-vs-wf_vblank-interruptible@c-hdmi-a1:
    - shard-adlp:         [PASS][44] -> [DMESG-WARN][45] ([Intel XE#4543]) +3 other tests dmesg-warn
   [44]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_flip@flip-vs-wf_vblank-interruptible@c-hdmi-a1.html
   [45]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-2/igt@kms_flip@flip-vs-wf_vblank-interruptible@c-hdmi-a1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
    - shard-bmg:          NOTRUN -> [SKIP][46] ([Intel XE#2293] / [Intel XE#2380])
   [46]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling@pipe-a-valid-mode:
    - shard-bmg:          NOTRUN -> [SKIP][47] ([Intel XE#2293])
   [47]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling@pipe-a-valid-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tiledg2rcccs-downscaling:
    - shard-bmg:          NOTRUN -> [SKIP][48] ([Intel XE#2380]) +1 other test skip
   [48]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tiledg2rcccs-downscaling.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling@pipe-a-valid-mode:
    - shard-adlp:         [PASS][49] -> [DMESG-WARN][50] ([Intel XE#2953] / [Intel XE#4173]) +5 other tests dmesg-warn
   [49]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-4/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling@pipe-a-valid-mode.html
   [50]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling@pipe-a-valid-mode.html

  * igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-pri-indfb-draw-render:
    - shard-dg2-set2:     NOTRUN -> [SKIP][51] ([Intel XE#651]) +13 other tests skip
   [51]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-pri-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
    - shard-bmg:          NOTRUN -> [SKIP][52] ([Intel XE#5390]) +3 other tests skip
   [52]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen.html

  * igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-indfb-plflip-blt:
    - shard-bmg:          NOTRUN -> [SKIP][53] ([Intel XE#2311]) +7 other tests skip
   [53]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-indfb-plflip-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-render:
    - shard-bmg:          NOTRUN -> [SKIP][54] ([Intel XE#2312]) +4 other tests skip
   [54]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
    - shard-bmg:          NOTRUN -> [SKIP][55] ([Intel XE#2313]) +9 other tests skip
   [55]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render.html

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-shrfb-msflip-blt:
    - shard-dg2-set2:     NOTRUN -> [SKIP][56] ([Intel XE#653]) +17 other tests skip
   [56]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_frontbuffer_tracking@psr-2p-primscrn-shrfb-msflip-blt.html

  * igt@kms_hdr@invalid-hdr:
    - shard-dg2-set2:     [PASS][57] -> [SKIP][58] ([Intel XE#455])
   [57]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-463/igt@kms_hdr@invalid-hdr.html
   [58]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-435/igt@kms_hdr@invalid-hdr.html

  * igt@kms_hdr@static-toggle:
    - shard-bmg:          NOTRUN -> [SKIP][59] ([Intel XE#1503])
   [59]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_hdr@static-toggle.html

  * igt@kms_plane_multiple@2x-tiling-y:
    - shard-bmg:          NOTRUN -> [SKIP][60] ([Intel XE#5021])
   [60]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_plane_multiple@2x-tiling-y.html
    - shard-dg2-set2:     NOTRUN -> [SKIP][61] ([Intel XE#5021])
   [61]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_plane_multiple@2x-tiling-y.html

  * igt@kms_pm_backlight@fade-with-suspend:
    - shard-dg2-set2:     NOTRUN -> [SKIP][62] ([Intel XE#870])
   [62]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_pm_backlight@fade-with-suspend.html
    - shard-bmg:          NOTRUN -> [SKIP][63] ([Intel XE#870])
   [63]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_pm_backlight@fade-with-suspend.html

  * igt@kms_pm_rpm@modeset-lpsp-stress-no-wait:
    - shard-bmg:          NOTRUN -> [SKIP][64] ([Intel XE#1439] / [Intel XE#3141] / [Intel XE#836])
   [64]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_pm_rpm@modeset-lpsp-stress-no-wait.html

  * igt@kms_psr2_sf@fbc-pr-cursor-plane-update-sf:
    - shard-dg2-set2:     NOTRUN -> [SKIP][65] ([Intel XE#1406] / [Intel XE#1489]) +3 other tests skip
   [65]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_psr2_sf@fbc-pr-cursor-plane-update-sf.html

  * igt@kms_psr2_sf@psr2-overlay-plane-move-continuous-exceed-fully-sf:
    - shard-bmg:          NOTRUN -> [SKIP][66] ([Intel XE#1406] / [Intel XE#1489]) +1 other test skip
   [66]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_psr2_sf@psr2-overlay-plane-move-continuous-exceed-fully-sf.html

  * igt@kms_psr2_su@frontbuffer-xrgb8888:
    - shard-dg2-set2:     NOTRUN -> [SKIP][67] ([Intel XE#1122] / [Intel XE#1406])
   [67]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@kms_psr2_su@frontbuffer-xrgb8888.html

  * igt@kms_psr@psr2-cursor-plane-move:
    - shard-bmg:          NOTRUN -> [SKIP][68] ([Intel XE#1406] / [Intel XE#2234] / [Intel XE#2850]) +3 other tests skip
   [68]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_psr@psr2-cursor-plane-move.html

  * igt@kms_psr@psr2-primary-render:
    - shard-dg2-set2:     NOTRUN -> [SKIP][69] ([Intel XE#1406] / [Intel XE#2850] / [Intel XE#929]) +5 other tests skip
   [69]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@kms_psr@psr2-primary-render.html

  * igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180:
    - shard-dg2-set2:     NOTRUN -> [SKIP][70] ([Intel XE#1127])
   [70]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180.html

  * igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
    - shard-bmg:          NOTRUN -> [SKIP][71] ([Intel XE#3414] / [Intel XE#3904])
   [71]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_rotation_crc@sprite-rotation-90-pos-100-0.html
    - shard-dg2-set2:     NOTRUN -> [SKIP][72] ([Intel XE#3414])
   [72]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_rotation_crc@sprite-rotation-90-pos-100-0.html

  * igt@kms_setmode@invalid-clone-single-crtc:
    - shard-bmg:          NOTRUN -> [SKIP][73] ([Intel XE#1435])
   [73]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_setmode@invalid-clone-single-crtc.html

  * igt@kms_vrr@flipline:
    - shard-bmg:          NOTRUN -> [SKIP][74] ([Intel XE#1499])
   [74]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_vrr@flipline.html

  * igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all:
    - shard-bmg:          [PASS][75] -> [FAIL][76] ([Intel XE#5937])
   [75]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-4/igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all.html
   [76]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-8/igt@sriov_basic@enable-vfs-bind-unbind-each-numvfs-all.html

  * igt@xe_copy_basic@mem-copy-linear-0x3fff:
    - shard-dg2-set2:     NOTRUN -> [SKIP][77] ([Intel XE#1123])
   [77]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@xe_copy_basic@mem-copy-linear-0x3fff.html

  * igt@xe_create@multigpu-create-massive-size:
    - shard-bmg:          NOTRUN -> [SKIP][78] ([Intel XE#2504])
   [78]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@xe_create@multigpu-create-massive-size.html

  * igt@xe_eu_stall@invalid-event-report-count:
    - shard-dg2-set2:     NOTRUN -> [SKIP][79] ([Intel XE#5626]) +1 other test skip
   [79]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@xe_eu_stall@invalid-event-report-count.html

  * igt@xe_eudebug@basic-vm-bind-vm-destroy-discovery:
    - shard-bmg:          NOTRUN -> [SKIP][80] ([Intel XE#4837]) +3 other tests skip
   [80]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@xe_eudebug@basic-vm-bind-vm-destroy-discovery.html

  * igt@xe_eudebug_online@interrupt-all-set-breakpoint:
    - shard-dg2-set2:     NOTRUN -> [SKIP][81] ([Intel XE#4837]) +6 other tests skip
   [81]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@xe_eudebug_online@interrupt-all-set-breakpoint.html

  * igt@xe_eudebug_sriov@deny-sriov:
    - shard-dg2-set2:     NOTRUN -> [SKIP][82] ([Intel XE#4518])
   [82]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_eudebug_sriov@deny-sriov.html

  * igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-userptr:
    - shard-bmg:          NOTRUN -> [SKIP][83] ([Intel XE#2322]) +2 other tests skip
   [83]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-userptr.html

  * igt@xe_exec_basic@multigpu-no-exec-null-rebind:
    - shard-dg2-set2:     NOTRUN -> [SKIP][84] ([Intel XE#1392])
   [84]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@xe_exec_basic@multigpu-no-exec-null-rebind.html

  * igt@xe_exec_basic@multigpu-once-bindexecqueue-userptr-invalidate:
    - shard-dg2-set2:     [PASS][85] -> [SKIP][86] ([Intel XE#1392]) +4 other tests skip
   [85]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-436/igt@xe_exec_basic@multigpu-once-bindexecqueue-userptr-invalidate.html
   [86]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@xe_exec_basic@multigpu-once-bindexecqueue-userptr-invalidate.html

  * igt@xe_exec_fault_mode@twice-invalid-fault:
    - shard-dg2-set2:     NOTRUN -> [SKIP][87] ([Intel XE#288]) +15 other tests skip
   [87]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_exec_fault_mode@twice-invalid-fault.html

  * igt@xe_exec_reset@parallel-gt-reset:
    - shard-adlp:         [PASS][88] -> [DMESG-WARN][89] ([Intel XE#3876])
   [88]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-4/igt@xe_exec_reset@parallel-gt-reset.html
   [89]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-8/igt@xe_exec_reset@parallel-gt-reset.html

  * igt@xe_exec_system_allocator@once-mmap-huge-nomemset:
    - shard-bmg:          NOTRUN -> [SKIP][90] ([Intel XE#4943]) +4 other tests skip
   [90]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@xe_exec_system_allocator@once-mmap-huge-nomemset.html

  * igt@xe_exec_system_allocator@threads-many-large-execqueues-malloc-multi-fault:
    - shard-dg2-set2:     NOTRUN -> [SKIP][91] ([Intel XE#4915]) +109 other tests skip
   [91]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@xe_exec_system_allocator@threads-many-large-execqueues-malloc-multi-fault.html

  * igt@xe_exec_threads@threads-bal-shared-vm-userptr-invalidate:
    - shard-adlp:         [PASS][92] -> [DMESG-FAIL][93] ([Intel XE#3876]) +2 other tests dmesg-fail
   [92]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-4/igt@xe_exec_threads@threads-bal-shared-vm-userptr-invalidate.html
   [93]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-8/igt@xe_exec_threads@threads-bal-shared-vm-userptr-invalidate.html

  * igt@xe_oa@whitelisted-registers-userspace-config:
    - shard-dg2-set2:     NOTRUN -> [SKIP][94] ([Intel XE#3573]) +2 other tests skip
   [94]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_oa@whitelisted-registers-userspace-config.html

  * igt@xe_pm@d3hot-i2c:
    - shard-dg2-set2:     NOTRUN -> [SKIP][95] ([Intel XE#5742])
   [95]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@xe_pm@d3hot-i2c.html
    - shard-bmg:          NOTRUN -> [SKIP][96] ([Intel XE#5742])
   [96]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@xe_pm@d3hot-i2c.html

  * igt@xe_pm@s2idle-multiple-execs:
    - shard-adlp:         [PASS][97] -> [DMESG-WARN][98] ([Intel XE#2953] / [Intel XE#4173] / [Intel XE#4504])
   [97]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-3/igt@xe_pm@s2idle-multiple-execs.html
   [98]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-3/igt@xe_pm@s2idle-multiple-execs.html

  * igt@xe_pxp@pxp-stale-bo-bind-post-rpm:
    - shard-dg2-set2:     NOTRUN -> [SKIP][99] ([Intel XE#4733])
   [99]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_pxp@pxp-stale-bo-bind-post-rpm.html

  * igt@xe_query@multigpu-query-gt-list:
    - shard-dg2-set2:     NOTRUN -> [SKIP][100] ([Intel XE#944]) +1 other test skip
   [100]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-432/igt@xe_query@multigpu-query-gt-list.html

  * igt@xe_sriov_auto_provisioning@selfconfig-reprovision-increase-numvfs:
    - shard-dg2-set2:     NOTRUN -> [SKIP][101] ([Intel XE#4130])
   [101]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-434/igt@xe_sriov_auto_provisioning@selfconfig-reprovision-increase-numvfs.html

  
#### Possible fixes ####

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-a-dp-4:
    - shard-dg2-set2:     [INCOMPLETE][102] ([Intel XE#1727] / [Intel XE#2705] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4522]) -> [PASS][103]
   [102]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-436/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-a-dp-4.html
   [103]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-433/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc@pipe-a-dp-4.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
    - shard-bmg:          [SKIP][104] ([Intel XE#2291]) -> [PASS][105]
   [104]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
   [105]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
    - shard-bmg:          [DMESG-WARN][106] ([Intel XE#5354]) -> [PASS][107]
   [106]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-2/igt@kms_cursor_legacy@cursora-vs-flipb-varying-size.html
   [107]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-1/igt@kms_cursor_legacy@cursora-vs-flipb-varying-size.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc:
    - shard-bmg:          [SKIP][108] ([Intel XE#1340]) -> [PASS][109]
   [108]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_dither@fb-8bpc-vs-panel-6bpc.html
   [109]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_dither@fb-8bpc-vs-panel-6bpc.html

  * igt@kms_dp_aux_dev:
    - shard-bmg:          [SKIP][110] ([Intel XE#3009]) -> [PASS][111]
   [110]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_dp_aux_dev.html
   [111]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_dp_aux_dev.html

  * igt@kms_flip@2x-flip-vs-dpms-on-nop-interruptible:
    - shard-bmg:          [SKIP][112] ([Intel XE#2316]) -> [PASS][113] +3 other tests pass
   [112]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_flip@2x-flip-vs-dpms-on-nop-interruptible.html
   [113]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_flip@2x-flip-vs-dpms-on-nop-interruptible.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
    - shard-lnl:          [FAIL][114] ([Intel XE#301]) -> [PASS][115]
   [114]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-lnl-3/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
   [115]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-lnl-1/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-bmg:          [INCOMPLETE][116] ([Intel XE#2049] / [Intel XE#2597]) -> [PASS][117] +1 other test pass
   [116]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-7/igt@kms_flip@flip-vs-suspend.html
   [117]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_flip@flip-vs-suspend.html
    - shard-dg2-set2:     [INCOMPLETE][118] ([Intel XE#2049] / [Intel XE#2597]) -> [PASS][119] +1 other test pass
   [118]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-433/igt@kms_flip@flip-vs-suspend.html
   [119]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_flip@plain-flip-interruptible@b-hdmi-a1:
    - shard-adlp:         [DMESG-WARN][120] ([Intel XE#4543]) -> [PASS][121] +1 other test pass
   [120]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_flip@plain-flip-interruptible@b-hdmi-a1.html
   [121]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-2/igt@kms_flip@plain-flip-interruptible@b-hdmi-a1.html

  * igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y:
    - shard-adlp:         [DMESG-FAIL][122] ([Intel XE#4543]) -> [PASS][123] +1 other test pass
   [122]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y.html
   [123]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-2/igt@kms_flip_tiling@flip-change-tiling@pipe-c-hdmi-a-1-y-to-y.html

  * igt@kms_flip_tiling@flip-change-tiling@pipe-d-hdmi-a-1-x-to-y:
    - shard-adlp:         [FAIL][124] ([Intel XE#1874]) -> [PASS][125]
   [124]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_flip_tiling@flip-change-tiling@pipe-d-hdmi-a-1-x-to-y.html
   [125]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-2/igt@kms_flip_tiling@flip-change-tiling@pipe-d-hdmi-a-1-x-to-y.html

  * igt@kms_hdr@invalid-hdr:
    - shard-bmg:          [SKIP][126] ([Intel XE#1503]) -> [PASS][127]
   [126]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-5/igt@kms_hdr@invalid-hdr.html
   [127]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-4/igt@kms_hdr@invalid-hdr.html

  * igt@kms_vblank@ts-continuation-suspend:
    - shard-adlp:         [DMESG-WARN][128] ([Intel XE#2953] / [Intel XE#4173]) -> [PASS][129] +3 other tests pass
   [128]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-9/igt@kms_vblank@ts-continuation-suspend.html
   [129]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-9/igt@kms_vblank@ts-continuation-suspend.html

  * {igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute}:
    - shard-bmg:          [ABORT][130] ([Intel XE#3970]) -> [PASS][131] +1 other test pass
   [130]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute.html
   [131]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute.html

  * igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-userptr-rebind:
    - shard-dg2-set2:     [SKIP][132] ([Intel XE#1392]) -> [PASS][133] +5 other tests pass
   [132]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-432/igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-userptr-rebind.html
   [133]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-436/igt@xe_exec_basic@multigpu-no-exec-bindexecqueue-userptr-rebind.html

  * igt@xe_exec_reset@parallel-gt-reset:
    - shard-dg2-set2:     [DMESG-WARN][134] ([Intel XE#3876]) -> [PASS][135]
   [134]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-432/igt@xe_exec_reset@parallel-gt-reset.html
   [135]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-435/igt@xe_exec_reset@parallel-gt-reset.html

  * {igt@xe_exec_system_allocator@many-stride-malloc-prefetch}:
    - shard-bmg:          [WARN][136] ([Intel XE#5786]) -> [PASS][137]
   [136]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-7/igt@xe_exec_system_allocator@many-stride-malloc-prefetch.html
   [137]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-7/igt@xe_exec_system_allocator@many-stride-malloc-prefetch.html

  * igt@xe_pmu@gt-frequency:
    - shard-dg2-set2:     [FAIL][138] ([Intel XE#4819]) -> [PASS][139] +1 other test pass
   [138]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-434/igt@xe_pmu@gt-frequency.html
   [139]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-464/igt@xe_pmu@gt-frequency.html
    - shard-lnl:          [FAIL][140] ([Intel XE#5841]) -> [PASS][141] +1 other test pass
   [140]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-lnl-7/igt@xe_pmu@gt-frequency.html
   [141]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-lnl-3/igt@xe_pmu@gt-frequency.html

  
#### Warnings ####

  * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc:
    - shard-dg2-set2:     [INCOMPLETE][142] ([Intel XE#1727] / [Intel XE#2705] / [Intel XE#3113] / [Intel XE#4212] / [Intel XE#4345] / [Intel XE#4522]) -> [INCOMPLETE][143] ([Intel XE#1727] / [Intel XE#3113] / [Intel XE#4345])
   [142]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-436/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc.html
   [143]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-433/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc.html

  * igt@kms_flip@flip-vs-rmfb-interruptible:
    - shard-adlp:         [DMESG-WARN][144] ([Intel XE#5208]) -> [DMESG-WARN][145] ([Intel XE#4543] / [Intel XE#5208])
   [144]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-8/igt@kms_flip@flip-vs-rmfb-interruptible.html
   [145]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-9/igt@kms_flip@flip-vs-rmfb-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-adlp:         [DMESG-WARN][146] ([Intel XE#4543]) -> [DMESG-WARN][147] ([Intel XE#2953] / [Intel XE#4173] / [Intel XE#4543])
   [146]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-adlp-8/igt@kms_flip@flip-vs-suspend.html
   [147]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-adlp-9/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt:
    - shard-bmg:          [SKIP][148] ([Intel XE#2311]) -> [SKIP][149] ([Intel XE#2312]) +4 other tests skip
   [148]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-3/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt.html
   [149]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
    - shard-bmg:          [SKIP][150] ([Intel XE#2312]) -> [SKIP][151] ([Intel XE#5390]) +1 other test skip
   [150]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt.html
   [151]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff:
    - shard-bmg:          [SKIP][152] ([Intel XE#5390]) -> [SKIP][153] ([Intel XE#2312]) +2 other tests skip
   [152]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff.html
   [153]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff.html

  * igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-indfb-msflip-blt:
    - shard-bmg:          [SKIP][154] ([Intel XE#2312]) -> [SKIP][155] ([Intel XE#2311]) +9 other tests skip
   [154]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-indfb-msflip-blt.html
   [155]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-indfb-msflip-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-wc:
    - shard-bmg:          [SKIP][156] ([Intel XE#2313]) -> [SKIP][157] ([Intel XE#2312]) +4 other tests skip
   [156]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-3/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-wc.html
   [157]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-wc.html

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt:
    - shard-bmg:          [SKIP][158] ([Intel XE#2312]) -> [SKIP][159] ([Intel XE#2313]) +7 other tests skip
   [158]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-6/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt.html
   [159]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt.html

  * igt@kms_hdr@brightness-with-hdr:
    - shard-bmg:          [SKIP][160] ([Intel XE#3374] / [Intel XE#3544]) -> [SKIP][161] ([Intel XE#3544])
   [160]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-4/igt@kms_hdr@brightness-with-hdr.html
   [161]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-1/igt@kms_hdr@brightness-with-hdr.html

  * igt@kms_tiled_display@basic-test-pattern:
    - shard-bmg:          [SKIP][162] ([Intel XE#2426]) -> [FAIL][163] ([Intel XE#1729])
   [162]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-4/igt@kms_tiled_display@basic-test-pattern.html
   [163]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-1/igt@kms_tiled_display@basic-test-pattern.html
    - shard-dg2-set2:     [FAIL][164] ([Intel XE#1729]) -> [SKIP][165] ([Intel XE#362])
   [164]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-dg2-435/igt@kms_tiled_display@basic-test-pattern.html
   [165]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-dg2-463/igt@kms_tiled_display@basic-test-pattern.html

  * igt@kms_tiled_display@basic-test-pattern-with-chamelium:
    - shard-bmg:          [SKIP][166] ([Intel XE#2509]) -> [SKIP][167] ([Intel XE#2426])
   [166]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b/shard-bmg-1/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
   [167]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/shard-bmg-2/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [Intel XE#1122]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1122
  [Intel XE#1123]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1123
  [Intel XE#1124]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1124
  [Intel XE#1127]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1127
  [Intel XE#1188]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1188
  [Intel XE#1340]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1340
  [Intel XE#1392]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1392
  [Intel XE#1406]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1406
  [Intel XE#1435]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1435
  [Intel XE#1439]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1439
  [Intel XE#1475]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1475
  [Intel XE#1489]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1489
  [Intel XE#1499]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1499
  [Intel XE#1503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1503
  [Intel XE#1727]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1727
  [Intel XE#1729]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1729
  [Intel XE#1874]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1874
  [Intel XE#2049]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2049
  [Intel XE#2191]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2191
  [Intel XE#2234]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2234
  [Intel XE#2252]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2252
  [Intel XE#2291]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2291
  [Intel XE#2293]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2293
  [Intel XE#2311]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2311
  [Intel XE#2312]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2312
  [Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313
  [Intel XE#2316]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2316
  [Intel XE#2320]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2320
  [Intel XE#2322]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2322
  [Intel XE#2325]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2325
  [Intel XE#2327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2327
  [Intel XE#2373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2373
  [Intel XE#2380]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2380
  [Intel XE#2426]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2426
  [Intel XE#2504]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2504
  [Intel XE#2509]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2509
  [Intel XE#2597]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2597
  [Intel XE#2652]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2652
  [Intel XE#2705]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2705
  [Intel XE#2850]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2850
  [Intel XE#288]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/288
  [Intel XE#2887]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2887
  [Intel XE#2907]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2907
  [Intel XE#2953]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2953
  [Intel XE#3009]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3009
  [Intel XE#301]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/301
  [Intel XE#306]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/306
  [Intel XE#307]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/307
  [Intel XE#308]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/308
  [Intel XE#3113]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3113
  [Intel XE#3141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3141
  [Intel XE#3304]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3304
  [Intel XE#3374]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3374
  [Intel XE#3414]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3414
  [Intel XE#3544]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3544
  [Intel XE#3573]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3573
  [Intel XE#362]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/362
  [Intel XE#373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/373
  [Intel XE#3876]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3876
  [Intel XE#3904]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3904
  [Intel XE#3970]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3970
  [Intel XE#4130]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4130
  [Intel XE#4173]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4173
  [Intel XE#4212]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4212
  [Intel XE#4345]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4345
  [Intel XE#4354]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4354
  [Intel XE#4356]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4356
  [Intel XE#4504]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4504
  [Intel XE#4518]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4518
  [Intel XE#4522]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4522
  [Intel XE#4543]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4543
  [Intel XE#455]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/455
  [Intel XE#4733]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4733
  [Intel XE#4819]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4819
  [Intel XE#4837]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4837
  [Intel XE#4915]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4915
  [Intel XE#4943]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4943
  [Intel XE#5021]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5021
  [Intel XE#5208]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5208
  [Intel XE#5354]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5354
  [Intel XE#5390]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5390
  [Intel XE#5428]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5428
  [Intel XE#5503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5503
  [Intel XE#5626]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5626
  [Intel XE#5742]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5742
  [Intel XE#5786]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5786
  [Intel XE#5841]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5841
  [Intel XE#5937]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5937
  [Intel XE#651]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/651
  [Intel XE#653]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/653
  [Intel XE#787]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/787
  [Intel XE#836]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/836
  [Intel XE#870]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/870
  [Intel XE#929]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/929
  [Intel XE#944]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/944


Build changes
-------------

  * Linux: xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b -> xe-pw-154504v1

  IGT_8539: 8539
  xe-3755-36a8f6b405f4a0def4462366cd17992897e1362b: 36a8f6b405f4a0def4462366cd17992897e1362b
  xe-pw-154504v1: 154504v1

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-154504v1/index.html

[-- Attachment #2: Type: text/html, Size: 58791 bytes --]

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Logan Gunthorpe]

On 2025-09-15 01:21, Vivek Kasireddy wrote:
> Typically, functions of the same PCI device (such as a PF and a VF)
> share the same bus and have a common root port and the PF provisions
> resources for the VF. Given this model, they can be considered
> compatible as far as P2PDMA access is considered.
> 
> Currently, although the distance (2) is correctly calculated for
> functions of the same device, an ACS check failure prevents P2P DMA
> access between them. Therefore, introduce a small function named
> pci_devfns_support_p2pdma() to determine if the provider and client
> belong to the same device and facilitate P2PDMA between them by
> not enforcing the ACS check.
> 
> However, since it is hard to determine if the device functions of
> any given PCI device are P2PDMA compatible, we only relax the ACS
> check enforcement for device functions of Intel GPUs. This is
> because the P2PDMA communication between the PF and VF of Intel
> GPUs is handled internally and does not typically involve the PCIe
> fabric.
> 
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: <linux-pci@vger.kernel.org>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>

This looks good to me, thanks.

Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Bjorn Helgaas]

[+cc Jason, also doing a lot of ACS work]

On Mon, Sep 15, 2025 at 12:21:05AM -0700, Vivek Kasireddy wrote:
> Typically, functions of the same PCI device (such as a PF and a VF)
> share the same bus and have a common root port and the PF provisions
> resources for the VF. Given this model, they can be considered
> compatible as far as P2PDMA access is considered.

These seem like more than just "typical".  Such devices *always* have
a common Root Port and a PF *always* provisions VF resources.  I guess
it's "typical" or at least common that a PF and VF share the same bus.

> Currently, although the distance (2) is correctly calculated for
> functions of the same device, an ACS check failure prevents P2P DMA
> access between them. Therefore, introduce a small function named
> pci_devfns_support_p2pdma() to determine if the provider and client
> belong to the same device and facilitate P2PDMA between them by
> not enforcing the ACS check.
> 
> However, since it is hard to determine if the device functions of
> any given PCI device are P2PDMA compatible, we only relax the ACS
> check enforcement for device functions of Intel GPUs. This is
> because the P2PDMA communication between the PF and VF of Intel
> GPUs is handled internally and does not typically involve the PCIe
> fabric.
> 
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: <linux-pci@vger.kernel.org>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
> v1 -> v2:
> - Relax the enforcment of ACS check only for Intel GPU functions
>   as they are P2PDMA compatible given the way the PF provisions
>   the resources among multiple VFs.
> 
> v2 -> v3:
> - s/pci_devs_are_p2pdma_compatible/pci_devfns_support_p2pdma
> - Improve the commit message to explain the reasoning behind
>   relaxing the ACS check enforcement only for Intel GPU functions.
> 
> v3 -> v4: (Logan)
> - Drop the dev_is_pf() hunk as no special handling is needed for PFs
> - Besides the provider, also check to see the client is an Intel GPU
> ---
>  drivers/pci/p2pdma.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index da5657a02007..0a1d884cd0ff 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -544,6 +544,19 @@ static unsigned long map_types_idx(struct pci_dev *client)
>  	return (pci_domain_nr(client->bus) << 16) | pci_dev_id(client);
>  }
>  
> +static bool pci_devfns_support_p2pdma(struct pci_dev *provider,
> +				      struct pci_dev *client)
> +{
> +	if (provider->vendor == PCI_VENDOR_ID_INTEL &&
> +	    client->vendor == PCI_VENDOR_ID_INTEL) {
> +		if ((pci_is_vga(provider) && pci_is_vga(client)) ||
> +		    (pci_is_display(provider) && pci_is_display(client)))
> +			return pci_physfn(provider) == pci_physfn(client);
> +	}

I know I've asked this before, but I'm still confused about how this
is related to PCIe r7.0, sec 7.7.12, which says that if an SR-IOV
device implements internal peer-to-peer transactions, ACS is required,
and ACS P2P Egress Control must be supported.

Are you saying that these Intel GPUs don't conform to this?

Or they do, but it's not enough to solve this issue?

Or something else?

Maybe if we add the right comment here, it will keep me from asking
again :)

> +	return false;
> +}
> +
>  /*
>   * Calculate the P2PDMA mapping type and distance between two PCI devices.
>   *
> @@ -643,7 +656,7 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
>  
>  	*dist = dist_a + dist_b;
>  
> -	if (!acs_cnt) {
> +	if (!acs_cnt || pci_devfns_support_p2pdma(provider, client)) {
>  		map_type = PCI_P2PDMA_MAP_BUS_ADDR;
>  		goto done;
>  	}
> -- 
> 2.50.1
> 

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 15, 2025 at 12:21:05AM -0700, Vivek Kasireddy wrote:
> Typically, functions of the same PCI device (such as a PF and a VF)
> share the same bus and have a common root port and the PF provisions
> resources for the VF. Given this model, they can be considered
> compatible as far as P2PDMA access is considered.

Huh? I'm not sure I understand what this is about. Please be more
clear what your use case is and what exactly is not working.

If it is talking about internal loopback within a single function
between PF and VF, then no, this is very expressly not something that
should be expected to work by default!

In fact I would consider any SRIOV capable device that had such a
behavior by default to be catastrophically security broken.

So this patch can't be talking about that, right?

Yet that is what this code seems to do?!?!?

> +static bool pci_devfns_support_p2pdma(struct pci_dev *provider,
> +				      struct pci_dev *client)
> +{
> +	if (provider->vendor == PCI_VENDOR_ID_INTEL &&
> +	    client->vendor == PCI_VENDOR_ID_INTEL) {
> +		if ((pci_is_vga(provider) && pci_is_vga(client)) ||
> +		    (pci_is_display(provider) && pci_is_display(client)))
> +			return pci_physfn(provider) == pci_physfn(client);
> +	}

Do not open code quirks like this in random places, if this device
supports some weird ACS behavior and does not include it in the ACS
Caps the right place is to supply an ACS quirk in quirks.c so all the
code knows about the device behavior, including the iommu grouping.

If your device supports P2P between VF and PF then iommu grouping must
put VFs in the PF's group and you loose VFIO support.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Tue, Sep 16, 2025 at 12:34:42PM -0500, Bjorn Helgaas wrote:

> I know I've asked this before, but I'm still confused about how this
> is related to PCIe r7.0, sec 7.7.12, which says that if an SR-IOV
> device implements internal peer-to-peer transactions, ACS is required,
> and ACS P2P Egress Control must be supported.

Right, certainly for SRIOV Linux has always taken the view that VFs
and PFs have NO internal loopback if there are no ACS caps.

The entire industry has aligned to this because having an hidden
uncontrolled internal loopback where the VF can reach the PF's BAR
would be catastrophically security broken for virtualization.

Virtualization is the main use case for having SRIOV in the first
place, so nobody would build an insecure internal loopback..

Jason

Re: [PATCH v4 4/5] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs

[Matthew Brost]

On Mon, Sep 15, 2025 at 12:21:08AM -0700, Vivek Kasireddy wrote:
> For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
> associated with a VF, we need to adjust and translate these addresses
> to LMEM addresses to make the BOs usable by the PF. Otherwise, the
> BOs (i.e, PCI BAR addresses) are only accessible by the CPU and not
> by the GPU.
> 
> In order to do the above, we first need to identify if the addresses
> associated with an imported BO (type ttm_bo_type_sg) belong to System
> RAM or a VF or other PCI devices. After we confirm that they belong to
> a VF, we convert the BAR addresses to DPAs and create a new dma_addr
> array (of type drm_pagemap_dma_addr) and populate it with the new
> addresses along with the segment sizes.
> 
> v2:
> - Use dma_addr array instead of sg table to store translated addresses
>   (Matt)
> 
> v3:
> - Remove the usage of iommu_iova_to_phys() as the imported BO would no
>   longer contain IOVAs and would instead have BAR addresses.
> 
> v4:
> - Take a reference on the VF's backing object in LMEM (Michal)
> - Create a new type for storing dma data
> 
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_bo.c             | 101 ++++++++++++++++++++++++-
>  drivers/gpu/drm/xe/xe_bo_types.h       |  12 +++
>  drivers/gpu/drm/xe/xe_sriov_pf_types.h |  19 +++++
>  3 files changed, 131 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index e6d16b34e5b5..a4e09fa88274 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -21,11 +21,13 @@
>  
>  #include <trace/events/gpu_mem.h>
>  
> +#include "regs/xe_bars.h"
>  #include "xe_device.h"
>  #include "xe_dma_buf.h"
>  #include "xe_drm_client.h"
>  #include "xe_ggtt.h"
>  #include "xe_gt.h"
> +#include "xe_gt_sriov_pf_config.h"
>  #include "xe_map.h"
>  #include "xe_migrate.h"
>  #include "xe_pm.h"
> @@ -33,6 +35,7 @@
>  #include "xe_pxp.h"
>  #include "xe_res_cursor.h"
>  #include "xe_shrinker.h"
> +#include "xe_sriov_pf_helpers.h"
>  #include "xe_sriov_vf_ccs.h"
>  #include "xe_trace_bo.h"
>  #include "xe_ttm_stolen_mgr.h"
> @@ -679,6 +682,90 @@ static int xe_bo_trigger_rebind(struct xe_device *xe, struct xe_bo *bo,
>  	return ret;
>  }
>  
> +static struct pci_dev *xe_find_vf_dev(struct xe_device *xe,
> +				      phys_addr_t phys)
> +{
> +	struct pci_dev *pdev, *pf_pdev = to_pci_dev(xe->drm.dev);
> +	resource_size_t io_start, io_size;
> +
> +	list_for_each_entry(pdev, &pf_pdev->bus->devices, bus_list) {
> +		if (pdev->is_physfn)
> +			continue;
> +
> +		io_start = pci_resource_start(pdev, LMEM_BAR);
> +		io_size = pci_resource_len(pdev, LMEM_BAR);
> +
> +		if (phys >= io_start &&
> +		    phys < (io_start + io_size - PAGE_SIZE))
> +			return pdev;
> +	}
> +
> +	return NULL;
> +}
> +
> +
> +static void xe_bo_translate_io_to_dpa(struct xe_bo *bo, struct sg_table *sg,
> +				      resource_size_t io_start, int vfid)
> +{
> +	struct xe_device *xe = xe_bo_device(bo);
> +	struct xe_gt *gt = xe_root_mmio_gt(xe);
> +	struct scatterlist *sgl;
> +	struct xe_bo *lmem_obj;
> +	phys_addr_t phys;
> +	dma_addr_t addr;
> +	u64 offset, i;
> +
> +	lmem_obj = xe_gt_sriov_pf_config_get_lmem_obj(gt, ++vfid);
> +	bo->dma_data.lmem_obj = xe_bo_get(lmem_obj);
> +
> +	for_each_sgtable_dma_sg(sg, sgl, i) {
> +		phys = sg_dma_address(sgl);
> +		offset = phys - io_start;
> +		addr = xe_bo_addr(lmem_obj, offset, sg_dma_len(sgl));

I think the last argument should XE_PAGE_SIZE to xe_bo_addr. There is an
assert in xe_bo_addr which checks the argument is PAGE_SIZE.

2539         xe_assert(xe, page_size <= PAGE_SIZE);

Longterm, I think we should just remove the last argument from
xe_bo_addr as it doesn't actually make any sense but for now to avoid an
assert popping if a larger dma-page in SG list was used (e.g., I think
it is possible for a sg_dma_len to be 2M) I'd use XE_PAGE_SIZE here.

> +
> +		bo->dma_data.dma_addr[i] = drm_pagemap_addr_encode(addr,
> +						DRM_INTERCONNECT_DRIVER,

DRM_INTERCONNECT_DRIVER is a bit inconistent here as elsewhere in code
we use XE_INTERCONNECT_VRAM. I forget why we added that define, but
either we should move that a place a bit more common then xe_svm.h or
drop it entirely as DRM_INTERCONNECT_DRIVER == XE_INTERCONNECT_VRAM
should even these mean the same thing. Not blocker for this series.

> +						get_order(sg_dma_len(sgl)),
> +						DMA_BIDIRECTIONAL);
> +	}
> +}
> +
> +static int xe_bo_sg_to_dma_addr_array(struct sg_table *sg, struct xe_bo *bo)
> +{
> +	struct xe_device *xe = xe_bo_device(bo);
> +	struct drm_pagemap_addr *dma_addr;
> +	resource_size_t io_start;
> +	struct pci_dev *pdev;
> +	phys_addr_t phys;
> +	int vfid;
> +
> +	if (!IS_SRIOV_PF(xe))
> +		return 0;
> +
> +	phys = sg_dma_address(sg->sgl);
> +	if (page_is_ram(PFN_DOWN(phys)))
> +		return 0;
> +
> +	pdev = xe_find_vf_dev(xe, phys);
> +	if (!pdev)
> +		return 0;
> +
> +	vfid = pci_iov_vf_id(pdev);
> +	if (vfid < 0)
> +		return 0;
> +
> +	dma_addr = kmalloc_array(sg->nents, sizeof(*dma_addr), GFP_KERNEL);
> +	if (!dma_addr)
> +		return -ENOMEM;
> +
> +	bo->is_devmem_external = true;
> +	bo->dma_data.dma_addr = dma_addr;
> +	io_start = pci_resource_start(pdev, LMEM_BAR);
> +	xe_bo_translate_io_to_dpa(bo, sg, io_start, vfid);
> +
> +	return 0;
> +}
> +
>  /*
>   * The dma-buf map_attachment() / unmap_attachment() is hooked up here.
>   * Note that unmapping the attachment is deferred to the next
> @@ -697,6 +784,7 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
>  	struct xe_device *xe = ttm_to_xe_device(ttm_bo->bdev);
>  	bool device_unplugged = drm_dev_is_unplugged(&xe->drm);
>  	struct sg_table *sg;
> +	int ret = 0;
>  
>  	xe_assert(xe, attach);
>  	xe_assert(xe, ttm_bo->ttm);
> @@ -721,13 +809,19 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
>  	if (IS_ERR(sg))
>  		return PTR_ERR(sg);
>  
> +	ret = xe_bo_sg_to_dma_addr_array(sg, ttm_to_xe_bo(ttm_bo));
> +	if (ret < 0) {
> +		dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> +		return ret;
> +	}
> +
>  	ttm_bo->sg = sg;
>  	xe_tt->sg = sg;
>  
>  out:
>  	ttm_bo_move_null(ttm_bo, new_res);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  /**
> @@ -1554,6 +1648,11 @@ static void xe_ttm_bo_delete_mem_notify(struct ttm_buffer_object *ttm_bo)
>  
>  		dma_buf_unmap_attachment(ttm_bo->base.import_attach, ttm_bo->sg,
>  					 DMA_BIDIRECTIONAL);
> +
> +		if (bo->is_devmem_external) {
> +			xe_bo_put(bo->dma_data.lmem_obj);
> +			kfree(bo->dma_data.dma_addr);
> +		}
>  		ttm_bo->sg = NULL;
>  		xe_tt->sg = NULL;
>  	}
> diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
> index d4fe3c8dca5b..8e416c4ffbca 100644
> --- a/drivers/gpu/drm/xe/xe_bo_types.h
> +++ b/drivers/gpu/drm/xe/xe_bo_types.h
> @@ -108,6 +108,18 @@ struct xe_bo {
>  	 * from default
>  	 */
>  	u64 min_align;
> +
> +	/**
> +	 * @is_devmem_external: Whether this BO is an imported dma-buf that
> +	 * is LMEM based.
> +	 */
> +	bool is_devmem_external;

I don't think you need this. Wouldn't a check dma_data.dma_addr or
dma_data.lmem_obj not being NULL?

Matt

> +
> +	/**
> +	 * @dma_data: DMA related data for an imported dmabuf BO that is LMEM
> +	 * based.
> +	 */
> +	struct xe_sriov_dma_data dma_data;
>  };
>  
>  #endif
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_types.h b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> index 956a88f9f213..6d5f923f7fc4 100644
> --- a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> +++ b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> @@ -11,6 +11,8 @@
>  
>  #include "xe_sriov_pf_service_types.h"
>  
> +struct xe_bo;
> +
>  /**
>   * struct xe_sriov_metadata - per-VF device level metadata
>   */
> @@ -42,4 +44,21 @@ struct xe_device_pf {
>  	struct xe_sriov_metadata *vfs;
>  };
>  
> +/**
> + * struct xe_sriov_dma_data - DMA related data for LMEM based imported dmabuf
> + * BOs that are associated with a sriov VF.
> + *
> + * The data in this structure is valid only if driver is running in the
> + * @XE_SRIOV_MODE_PF mode.
> + */
> +struct xe_sriov_dma_data {
> +	/**
> +	 * @dma_addr: An array to store DMA addresses (DPAs) for imported
> +	 * dmabuf BOs that are LMEM based.
> +	 */
> +	struct drm_pagemap_addr *dma_addr;
> +
> +	/** @lmem_obj: Ref taken on the LMEM obj that backs a VF's quota */
> +	struct xe_bo *lmem_obj;
> +};
>  #endif
> -- 
> 2.50.1
> 

Re: [PATCH v4 5/5] drm/xe/pt: Add an additional check for dmabuf BOs while doing bind

[Matthew Brost]

On Mon, Sep 15, 2025 at 12:21:09AM -0700, Vivek Kasireddy wrote:
> If a BO's is_devmem_external flag is set, it means that it is an
> imported dmabuf BO that has a backing store in VRAM. Therefore, in
> this case, need to iterate over its dma_addr array.
> 
> v2:
> - Use a cursor to iterate over the entries in the dma_addr array
>   instead of relying on SG iterator (Matt)
> 
> v3:
> - Since XE_PPGTT_PTE_DM is added to the PTE flags in all cases,
>   remove the bo->is_devmem_external check added in v2
> 
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_pt.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index 01eea8eb1779..a4b60fbcbc74 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -760,6 +760,10 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
>  
>  	xe_walk.default_vram_pte |= XE_PPGTT_PTE_DM;
>  	xe_walk.dma_offset = bo ? vram_region_gpu_offset(bo->ttm.resource) : 0;
> +
> +	if (bo && bo->is_devmem_external)
> +		xe_walk.dma_offset = 0;
> +
>  	if (!range)
>  		xe_bo_assert_held(bo);
>  
> @@ -770,6 +774,10 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
>  		else if (xe_bo_is_vram(bo) || xe_bo_is_stolen(bo))
>  			xe_res_first(bo->ttm.resource, xe_vma_bo_offset(vma),
>  				     xe_vma_size(vma), &curs);
> +		else if (bo && bo->is_devmem_external)

See my comment in previous patch, I think is_devmem_external can be dropped.

This patch LGTM though:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> +			xe_res_first_dma(bo->dma_data.dma_addr,
> +					 xe_vma_bo_offset(vma),
> +					 xe_vma_size(vma), &curs);
>  		else
>  			xe_res_first_sg(xe_bo_sg(bo), xe_vma_bo_offset(vma),
>  					xe_vma_size(vma), &curs);
> -- 
> 2.50.1
> 

Re: [PATCH v4 4/5] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs

[Matthew Brost]

On Mon, Sep 15, 2025 at 12:21:08AM -0700, Vivek Kasireddy wrote:
> For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
> associated with a VF, we need to adjust and translate these addresses
> to LMEM addresses to make the BOs usable by the PF. Otherwise, the
> BOs (i.e, PCI BAR addresses) are only accessible by the CPU and not
> by the GPU.
> 
> In order to do the above, we first need to identify if the addresses
> associated with an imported BO (type ttm_bo_type_sg) belong to System
> RAM or a VF or other PCI devices. After we confirm that they belong to
> a VF, we convert the BAR addresses to DPAs and create a new dma_addr
> array (of type drm_pagemap_dma_addr) and populate it with the new
> addresses along with the segment sizes.
> 
> v2:
> - Use dma_addr array instead of sg table to store translated addresses
>   (Matt)
> 
> v3:
> - Remove the usage of iommu_iova_to_phys() as the imported BO would no
>   longer contain IOVAs and would instead have BAR addresses.
> 
> v4:
> - Take a reference on the VF's backing object in LMEM (Michal)
> - Create a new type for storing dma data
> 
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_bo.c             | 101 ++++++++++++++++++++++++-
>  drivers/gpu/drm/xe/xe_bo_types.h       |  12 +++
>  drivers/gpu/drm/xe/xe_sriov_pf_types.h |  19 +++++
>  3 files changed, 131 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index e6d16b34e5b5..a4e09fa88274 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -21,11 +21,13 @@
>  
>  #include <trace/events/gpu_mem.h>
>  
> +#include "regs/xe_bars.h"
>  #include "xe_device.h"
>  #include "xe_dma_buf.h"
>  #include "xe_drm_client.h"
>  #include "xe_ggtt.h"
>  #include "xe_gt.h"
> +#include "xe_gt_sriov_pf_config.h"
>  #include "xe_map.h"
>  #include "xe_migrate.h"
>  #include "xe_pm.h"
> @@ -33,6 +35,7 @@
>  #include "xe_pxp.h"
>  #include "xe_res_cursor.h"
>  #include "xe_shrinker.h"
> +#include "xe_sriov_pf_helpers.h"
>  #include "xe_sriov_vf_ccs.h"
>  #include "xe_trace_bo.h"
>  #include "xe_ttm_stolen_mgr.h"
> @@ -679,6 +682,90 @@ static int xe_bo_trigger_rebind(struct xe_device *xe, struct xe_bo *bo,
>  	return ret;
>  }
>  
> +static struct pci_dev *xe_find_vf_dev(struct xe_device *xe,
> +				      phys_addr_t phys)
> +{
> +	struct pci_dev *pdev, *pf_pdev = to_pci_dev(xe->drm.dev);
> +	resource_size_t io_start, io_size;
> +
> +	list_for_each_entry(pdev, &pf_pdev->bus->devices, bus_list) {
> +		if (pdev->is_physfn)
> +			continue;
> +
> +		io_start = pci_resource_start(pdev, LMEM_BAR);
> +		io_size = pci_resource_len(pdev, LMEM_BAR);
> +
> +		if (phys >= io_start &&
> +		    phys < (io_start + io_size - PAGE_SIZE))
> +			return pdev;
> +	}
> +
> +	return NULL;
> +}
> +
> +
> +static void xe_bo_translate_io_to_dpa(struct xe_bo *bo, struct sg_table *sg,
> +				      resource_size_t io_start, int vfid)
> +{
> +	struct xe_device *xe = xe_bo_device(bo);
> +	struct xe_gt *gt = xe_root_mmio_gt(xe);
> +	struct scatterlist *sgl;
> +	struct xe_bo *lmem_obj;
> +	phys_addr_t phys;
> +	dma_addr_t addr;
> +	u64 offset, i;
> +
> +	lmem_obj = xe_gt_sriov_pf_config_get_lmem_obj(gt, ++vfid);
> +	bo->dma_data.lmem_obj = xe_bo_get(lmem_obj);

Since we're taking references here, and if those leak it could be quite
problematic, I'd assert that bo->dma_data.lmem_obj is NULL before
assigning it.

Additionally, I've updated the flow so that
xe_gt_sriov_pf_config_get_lmem_obj takes the BO reference under the
xe_gt_sriov_pf_master_mutex lock. This is typically the correct approach
when looking up an object under a lock to ensure it doesn't immediately
disappear after dropping the lock.

Matt 

> +
> +	for_each_sgtable_dma_sg(sg, sgl, i) {
> +		phys = sg_dma_address(sgl);
> +		offset = phys - io_start;
> +		addr = xe_bo_addr(lmem_obj, offset, sg_dma_len(sgl));
> +
> +		bo->dma_data.dma_addr[i] = drm_pagemap_addr_encode(addr,
> +						DRM_INTERCONNECT_DRIVER,
> +						get_order(sg_dma_len(sgl)),
> +						DMA_BIDIRECTIONAL);
> +	}
> +}
> +
> +static int xe_bo_sg_to_dma_addr_array(struct sg_table *sg, struct xe_bo *bo)
> +{
> +	struct xe_device *xe = xe_bo_device(bo);
> +	struct drm_pagemap_addr *dma_addr;
> +	resource_size_t io_start;
> +	struct pci_dev *pdev;
> +	phys_addr_t phys;
> +	int vfid;
> +
> +	if (!IS_SRIOV_PF(xe))
> +		return 0;
> +
> +	phys = sg_dma_address(sg->sgl);
> +	if (page_is_ram(PFN_DOWN(phys)))
> +		return 0;
> +
> +	pdev = xe_find_vf_dev(xe, phys);
> +	if (!pdev)
> +		return 0;
> +
> +	vfid = pci_iov_vf_id(pdev);
> +	if (vfid < 0)
> +		return 0;
> +
> +	dma_addr = kmalloc_array(sg->nents, sizeof(*dma_addr), GFP_KERNEL);
> +	if (!dma_addr)
> +		return -ENOMEM;
> +
> +	bo->is_devmem_external = true;
> +	bo->dma_data.dma_addr = dma_addr;
> +	io_start = pci_resource_start(pdev, LMEM_BAR);
> +	xe_bo_translate_io_to_dpa(bo, sg, io_start, vfid);
> +
> +	return 0;
> +}
> +
>  /*
>   * The dma-buf map_attachment() / unmap_attachment() is hooked up here.
>   * Note that unmapping the attachment is deferred to the next
> @@ -697,6 +784,7 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
>  	struct xe_device *xe = ttm_to_xe_device(ttm_bo->bdev);
>  	bool device_unplugged = drm_dev_is_unplugged(&xe->drm);
>  	struct sg_table *sg;
> +	int ret = 0;
>  
>  	xe_assert(xe, attach);
>  	xe_assert(xe, ttm_bo->ttm);
> @@ -721,13 +809,19 @@ static int xe_bo_move_dmabuf(struct ttm_buffer_object *ttm_bo,
>  	if (IS_ERR(sg))
>  		return PTR_ERR(sg);
>  
> +	ret = xe_bo_sg_to_dma_addr_array(sg, ttm_to_xe_bo(ttm_bo));
> +	if (ret < 0) {
> +		dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> +		return ret;
> +	}
> +
>  	ttm_bo->sg = sg;
>  	xe_tt->sg = sg;
>  
>  out:
>  	ttm_bo_move_null(ttm_bo, new_res);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  /**
> @@ -1554,6 +1648,11 @@ static void xe_ttm_bo_delete_mem_notify(struct ttm_buffer_object *ttm_bo)
>  
>  		dma_buf_unmap_attachment(ttm_bo->base.import_attach, ttm_bo->sg,
>  					 DMA_BIDIRECTIONAL);
> +
> +		if (bo->is_devmem_external) {
> +			xe_bo_put(bo->dma_data.lmem_obj);
> +			kfree(bo->dma_data.dma_addr);
> +		}
>  		ttm_bo->sg = NULL;
>  		xe_tt->sg = NULL;
>  	}
> diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
> index d4fe3c8dca5b..8e416c4ffbca 100644
> --- a/drivers/gpu/drm/xe/xe_bo_types.h
> +++ b/drivers/gpu/drm/xe/xe_bo_types.h
> @@ -108,6 +108,18 @@ struct xe_bo {
>  	 * from default
>  	 */
>  	u64 min_align;
> +
> +	/**
> +	 * @is_devmem_external: Whether this BO is an imported dma-buf that
> +	 * is LMEM based.
> +	 */
> +	bool is_devmem_external;
> +
> +	/**
> +	 * @dma_data: DMA related data for an imported dmabuf BO that is LMEM
> +	 * based.
> +	 */
> +	struct xe_sriov_dma_data dma_data;
>  };
>  
>  #endif
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_types.h b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> index 956a88f9f213..6d5f923f7fc4 100644
> --- a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> +++ b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> @@ -11,6 +11,8 @@
>  
>  #include "xe_sriov_pf_service_types.h"
>  
> +struct xe_bo;
> +
>  /**
>   * struct xe_sriov_metadata - per-VF device level metadata
>   */
> @@ -42,4 +44,21 @@ struct xe_device_pf {
>  	struct xe_sriov_metadata *vfs;
>  };
>  
> +/**
> + * struct xe_sriov_dma_data - DMA related data for LMEM based imported dmabuf
> + * BOs that are associated with a sriov VF.
> + *
> + * The data in this structure is valid only if driver is running in the
> + * @XE_SRIOV_MODE_PF mode.
> + */
> +struct xe_sriov_dma_data {
> +	/**
> +	 * @dma_addr: An array to store DMA addresses (DPAs) for imported
> +	 * dmabuf BOs that are LMEM based.
> +	 */
> +	struct drm_pagemap_addr *dma_addr;
> +
> +	/** @lmem_obj: Ref taken on the LMEM obj that backs a VF's quota */
> +	struct xe_bo *lmem_obj;
> +};
>  #endif
> -- 
> 2.50.1
> 

Re: [PATCH v4 3/5] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM

[Matthew Brost]

On Mon, Sep 15, 2025 at 12:21:07AM -0700, Vivek Kasireddy wrote:
> To properly import a dmabuf that is associated with a VF (or that
> originates in a Guest VM that includes a VF), we need to know where
> in LMEM the VF's allocated regions exist. Therefore, introduce a
> new helper to return the object that backs the VF's regions in LMEM.
> 
> v2:
> - Make the helper return the LMEM object instead of the start address
> 
> v3:
> - Move the declaration of the helper under other lmem helpers (Michal)
> 
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 23 ++++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h |  1 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> index 6344b5205c08..1bfcd35cc8ef 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> @@ -1535,6 +1535,29 @@ u64 xe_gt_sriov_pf_config_get_lmem(struct xe_gt *gt, unsigned int vfid)
>  	return size;
>  }
>  
> +/**
> + * xe_gt_sriov_pf_config_get_lmem_obj - Get VF's LMEM BO.
> + * @gt: the &xe_gt
> + * @vfid: the VF identifier
> + *
> + * This function can only be called on PF.
> + *
> + * Return: BO that is backing VF's quota in LMEM.
> + */
> +struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt,
> +						 unsigned int vfid)
> +{
> +	struct xe_gt_sriov_config *config;
> +	struct xe_bo *lmem_obj;
> +
> +	mutex_lock(xe_gt_sriov_pf_master_mutex(gt));
> +	config = pf_pick_vf_config(gt, vfid);
> +	lmem_obj = config->lmem_obj;

As noted in the following patch, I'd take the reference to lmem_obj
under the xe_gt_sriov_pf_master_mutex.

Matt

> +	mutex_unlock(xe_gt_sriov_pf_master_mutex(gt));
> +
> +	return lmem_obj;
> +}
> +
>  /**
>   * xe_gt_sriov_pf_config_set_lmem - Provision VF with LMEM.
>   * @gt: the &xe_gt (can't be media)
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> index 513e6512a575..bbc5c238cbf6 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> @@ -36,6 +36,7 @@ int xe_gt_sriov_pf_config_set_lmem(struct xe_gt *gt, unsigned int vfid, u64 size
>  int xe_gt_sriov_pf_config_set_fair_lmem(struct xe_gt *gt, unsigned int vfid, unsigned int num_vfs);
>  int xe_gt_sriov_pf_config_bulk_set_lmem(struct xe_gt *gt, unsigned int vfid, unsigned int num_vfs,
>  					u64 size);
> +struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt, unsigned int vfid);
>  
>  u32 xe_gt_sriov_pf_config_get_exec_quantum(struct xe_gt *gt, unsigned int vfid);
>  int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt, unsigned int vfid, u32 exec_quantum);
> -- 
> 2.50.1
> 

Re: [PATCH v4 2/5] drm/xe/dmabuf: Don't migrate BO to System RAM if P2P check succeeds

[Thomas Hellström]

Hi,

On Mon, 2025-09-15 at 00:21 -0700, Vivek Kasireddy wrote:
> If the P2P test (i.e, pci_p2pdma_distance()) is successful, then it
> means that the importer can directly access the BO located in VRAM.
> Therefore, in this specific case, do not migrate the BO to System
> RAM before exporting it.
> 
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_dma_buf.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c
> b/drivers/gpu/drm/xe/xe_dma_buf.c
> index a7d67725c3ee..04082e3e4295 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -52,7 +52,7 @@ static int xe_dma_buf_pin(struct dma_buf_attachment
> *attach)
>  	struct xe_bo *bo = gem_to_xe_bo(obj);
>  	struct xe_device *xe = xe_bo_device(bo);
>  	struct drm_exec *exec = XE_VALIDATION_UNSUPPORTED;
> -	int ret;
> +	int ret = 0;
>  
>  	/*
>  	 * For now only support pinning in TT memory, for two
> reasons:
> @@ -64,7 +64,8 @@ static int xe_dma_buf_pin(struct dma_buf_attachment
> *attach)
>  		return -EINVAL;
>  	}
>  
> -	ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
> +	if (!attach->peer2peer)
> +		ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);

From review of previous series:

"Pinning in VRAM is an ongoing discussion and there are many reasons
for
allowing that. However we need to sort out how the accounting should be
done and how regressions should avoided along the path to the final
solution which is cgroups-based.

So until that has been sorted out, there are no exceptions for special
use-cases that don't fit in that plan."

(I have an RFC patch out that if all stakeholders agree should fix
this).

https://patchwork.freedesktop.org/series/154593/

And also a question, can't the guest virtio-gpu KMD support
move_notify() Does it really pin the imported VF fb fullscreen on the
physical screen?


Thanks,
Thomas


>  	if (ret) {
>  		if (ret != -EINTR && ret != -ERESTARTSYS)
>  			drm_dbg(&xe->drm,

Re: [PATCH v4 3/5] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM

[Thomas Hellström]

On Mon, 2025-09-15 at 00:21 -0700, Vivek Kasireddy wrote:
> To properly import a dmabuf that is associated with a VF (or that
> originates in a Guest VM that includes a VF), we need to know where
> in LMEM the VF's allocated regions exist. Therefore, introduce a
> new helper to return the object that backs the VF's regions in LMEM.
> 
> v2:
> - Make the helper return the LMEM object instead of the start address
> 
> v3:
> - Move the declaration of the helper under other lmem helpers
> (Michal)

In XeKMD we're typically using VRAM instead of LMEM, IMO we should try
to be consistent with this.

> 
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 23
> ++++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h |  1 +
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> index 6344b5205c08..1bfcd35cc8ef 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> @@ -1535,6 +1535,29 @@ u64 xe_gt_sriov_pf_config_get_lmem(struct
> xe_gt *gt, unsigned int vfid)
>  	return size;
>  }
>  
> +/**
> + * xe_gt_sriov_pf_config_get_lmem_obj - Get VF's LMEM BO.
> + * @gt: the &xe_gt
> + * @vfid: the VF identifier
> + *
> + * This function can only be called on PF.
> + *
> + * Return: BO that is backing VF's quota in LMEM.
> + */
> +struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt,
> +						 unsigned int vfid)
> +{
> +	struct xe_gt_sriov_config *config;
> +	struct xe_bo *lmem_obj;
> +
> +	mutex_lock(xe_gt_sriov_pf_master_mutex(gt));
> +	config = pf_pick_vf_config(gt, vfid);
> +	lmem_obj = config->lmem_obj;

Bump the reference count? I think Matt mentioned this as well?

> +	mutex_unlock(xe_gt_sriov_pf_master_mutex(gt));
> +
> +	return lmem_obj;
> +}
> +
>  /**
>   * xe_gt_sriov_pf_config_set_lmem - Provision VF with LMEM.
>   * @gt: the &xe_gt (can't be media)
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> index 513e6512a575..bbc5c238cbf6 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.h
> @@ -36,6 +36,7 @@ int xe_gt_sriov_pf_config_set_lmem(struct xe_gt
> *gt, unsigned int vfid, u64 size
>  int xe_gt_sriov_pf_config_set_fair_lmem(struct xe_gt *gt, unsigned
> int vfid, unsigned int num_vfs);
>  int xe_gt_sriov_pf_config_bulk_set_lmem(struct xe_gt *gt, unsigned
> int vfid, unsigned int num_vfs,
>  					u64 size);
> +struct xe_bo *xe_gt_sriov_pf_config_get_lmem_obj(struct xe_gt *gt,
> unsigned int vfid);
>  
>  u32 xe_gt_sriov_pf_config_get_exec_quantum(struct xe_gt *gt,
> unsigned int vfid);
>  int xe_gt_sriov_pf_config_set_exec_quantum(struct xe_gt *gt,
> unsigned int vfid, u32 exec_quantum);

Re: [PATCH v4 3/5] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM

[Thomas Hellström]

On Tue, 2025-09-16 at 22:06 +0200, Thomas Hellström wrote:
> On Mon, 2025-09-15 at 00:21 -0700, Vivek Kasireddy wrote:
> > To properly import a dmabuf that is associated with a VF (or that
> > originates in a Guest VM that includes a VF), we need to know where
> > in LMEM the VF's allocated regions exist. Therefore, introduce a
> > new helper to return the object that backs the VF's regions in
> > LMEM.
> > 
> > v2:
> > - Make the helper return the LMEM object instead of the start
> > address
> > 
> > v3:
> > - Move the declaration of the helper under other lmem helpers
> > (Michal)
> 
> In XeKMD we're typically using VRAM instead of LMEM, IMO we should
> try
> to be consistent with this.

I actually notice that most of the SRIOV code uses LMEM instead of
VRAM, so I discussed with the other maintainers what would be the best
way moving forward here.

So if you could try as a general rule to avoid using "lmem" in other
files than the SRIOV files. Also if SRIOV functions or variable names
or fields mandate it, "lmem" is OK.

But in other files, functions and variable names, pleas use VRAM.

Thanks,
Thomas

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Jason,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On Mon, Sep 15, 2025 at 12:21:05AM -0700, Vivek Kasireddy wrote:
> > Typically, functions of the same PCI device (such as a PF and a VF)
> > share the same bus and have a common root port and the PF provisions
> > resources for the VF. Given this model, they can be considered
> > compatible as far as P2PDMA access is considered.
> 
> Huh? I'm not sure I understand what this is about. Please be more
> clear what your use case is and what exactly is not working.
> 
> If it is talking about internal loopback within a single function
> between PF and VF, then no, this is very expressly not something that
> should be expected to work by default!
> 
> In fact I would consider any SRIOV capable device that had such a
> behavior by default to be catastrophically security broken.
> 
> So this patch can't be talking about that, right?
> 
> Yet that is what this code seems to do?!?!?
Here is my use-case:
- Xe Graphics driver, bound to GPU PF on the Host provisions its resources
including VRAM (aka device/graphics memory) among all the VFs.

- A GPU VF device is bound to vfio-pci and assigned to a Linux VM which
is launched via Qemu.

- The Xe Graphics driver running inside the Linux VM creates a buffer in
the VF's portion (or share) of the VRAM and this buffer is shared with
Qemu. Qemu then requests vfio-pci driver to create a dmabuf associated
with this buffer. Note that I am testing with Leon's vfio-pci series included
(vfio/pci: Allow MMIO regions to be exported through dma-buf)

- Next, Qemu requests the GPU PF (via the Xe driver) to import (or access)
the dmabuf (or buffer) located in VF's portion of the VRAM. This is where a
problem occurs. 

The exporter (vfio-pci driver in this case) calls pci_p2pdma_map_type() to
determine the map type between both devices (GPU VF and PF) but it fails
due to the ACS enforcement check.

However, assuming that pci_p2pdma_map_type() did not fail, based on my
experiments, the GPU PF is still unable to access the buffer located in VF's
VRAM portion directly because it is represented using PCI BAR addresses.

The only way this seems to be working at the moment is if the BAR addresses
are translated into VRAM addresses that the GPU PF understands (this is done
done inside Xe driver on the Host using provisioning data). Note that this buffer
is accessible by the CPU using BAR addresses but it is very slow.

So, given that the GPU PF does not need to use PCIe fabric/machinery in order
to access the buffer located in GPU VF's portion of the VRAM in this use-case,
I figured adding a quirk (to not enforce ACS check) here would make sense. 

> 
> > +static bool pci_devfns_support_p2pdma(struct pci_dev *provider,
> > +				      struct pci_dev *client)
> > +{
> > +	if (provider->vendor == PCI_VENDOR_ID_INTEL &&
> > +	    client->vendor == PCI_VENDOR_ID_INTEL) {
> > +		if ((pci_is_vga(provider) && pci_is_vga(client)) ||
> > +		    (pci_is_display(provider) && pci_is_display(client)))
> > +			return pci_physfn(provider) == pci_physfn(client);
> > +	}
> 
> Do not open code quirks like this in random places, if this device
> supports some weird ACS behavior and does not include it in the ACS
> Caps the right place is to supply an ACS quirk in quirks.c so all the
> code knows about the device behavior, including the iommu grouping.
Ok, I'll move it to quirks.c.

> 
> If your device supports P2P between VF and PF then iommu grouping must
> put VFs in the PF's group and you loose VFIO support.
On my test system, it looks like the VFs and the PF are put into different
iommu groups. I am checking with our hardware folks to understand how this
is expected to work but does it mean that P2P between PF and VF is not
supported in my case?

Also, we do need VFIO support. Otherwise, I don't see any other way as to
how a GPU VF device can be assigned (or passthrough'd) to a Guest VM. 

Thanks,
Vivek
> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Thu, Sep 18, 2025 at 06:16:38AM +0000, Kasireddy, Vivek wrote:

> However, assuming that pci_p2pdma_map_type() did not fail, based on my
> experiments, the GPU PF is still unable to access the buffer located in VF's
> VRAM portion directly because it is represented using PCI BAR addresses.

In this case messing with ACS is completely wrong. If the intention is
to convay a some kind of "private" address representing the physical
VRAM then you need to use a DMABUF mechanism to do that, not deliver a
P2P address that the other side cannot access.

Christian told me dmabuf has such a private address mechanism, so
please figure out a way to use it..

> > Do not open code quirks like this in random places, if this device
> > supports some weird ACS behavior and does not include it in the ACS
> > Caps the right place is to supply an ACS quirk in quirks.c so all the
> > code knows about the device behavior, including the iommu grouping.
> Ok, I'll move it to quirks.c.

No, don't, it is completely wrong to mess with ACS flags for the
problem you are trying to solve.

> On my test system, it looks like the VFs and the PF are put into different
> iommu groups. I am checking with our hardware folks to understand how this
> is expected to work but does it mean that P2P between PF and VF is not
> supported in my case?

A special internal path through VRAM is outside the scope of iommu
grouping.

Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Jason,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On Thu, Sep 18, 2025 at 06:16:38AM +0000, Kasireddy, Vivek wrote:
> 
> > However, assuming that pci_p2pdma_map_type() did not fail, based on
> my
> > experiments, the GPU PF is still unable to access the buffer located in VF's
> > VRAM portion directly because it is represented using PCI BAR addresses.
> 
> In this case messing with ACS is completely wrong. If the intention is
> to convay a some kind of "private" address representing the physical
> VRAM then you need to use a DMABUF mechanism to do that, not deliver a
> P2P address that the other side cannot access.
I think using a PCI BAR Address works just fine in this case because the Xe
driver bound to PF on the Host can easily determine that it belongs to one
of the VFs and translate it into VRAM Address.

> 
> Christian told me dmabuf has such a private address mechanism, so
> please figure out a way to use it..
Even if such as a mechanism exists, we still need a way to prevent
pci_p2pdma_map_type() from failing when invoked by the exporter (vfio-pci).
Does it make sense to move this quirk into the exporter?

Also, AFAICS, translating BAR Address to VRAM Address can only be
done by the Xe driver bound to PF because it has access to provisioning
data. In other words, vfio-pci would not be able to share any other
address other than the BAR Address because it wouldn't know how to
translate it to VRAM Address.

> 
> > > Do not open code quirks like this in random places, if this device
> > > supports some weird ACS behavior and does not include it in the ACS
> > > Caps the right place is to supply an ACS quirk in quirks.c so all the
> > > code knows about the device behavior, including the iommu grouping.
> > Ok, I'll move it to quirks.c.
> 
> No, don't, it is completely wrong to mess with ACS flags for the
> problem you are trying to solve.
But I am not messing with any ACS flags here. I am just adding a quirk to
sidestep the ACS enforcement check given that the PF to VF access does
not involve the PCIe fabric in this case.

> 
> > On my test system, it looks like the VFs and the PF are put into different
> > iommu groups. I am checking with our hardware folks to understand how
> this
> > is expected to work but does it mean that P2P between PF and VF is not
> > supported in my case?
> 
> A special internal path through VRAM is outside the scope of iommu
> grouping.
The BAR to VRAM Address translation logic is being added to the Xe driver
as part of this patch series, so, nothing else needs to be done except a way
to enable the exporter(vfio-pci) to share the dmabuf with the PF without
having to rely on the outcome of pci_p2pdma_map_type() in this use-case.

Thanks,
Vivek

> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
> > In this case messing with ACS is completely wrong. If the intention is
> > to convay a some kind of "private" address representing the physical
> > VRAM then you need to use a DMABUF mechanism to do that, not deliver a
> > P2P address that the other side cannot access.

> I think using a PCI BAR Address works just fine in this case because the Xe
> driver bound to PF on the Host can easily determine that it belongs to one
> of the VFs and translate it into VRAM Address.

That isn't how the P2P or ACS mechansim works in Linux, it is about
the actual address used for DMA.

You can't translate a dma_addr_t to anything in the Xe PF driver
anyhow, once it goes through the IOMMU the necessary information is
lost. This is a fundamentally broken design to dma map something and
then try to reverse engineer the dma_addr_t back to something with
meaning.

> > Christian told me dmabuf has such a private address mechanism, so
> > please figure out a way to use it..
>
> Even if such as a mechanism exists, we still need a way to prevent
> pci_p2pdma_map_type() from failing when invoked by the exporter (vfio-pci).
> Does it make sense to move this quirk into the exporter?

When you export a private address through dmabuf the VFIO exporter
will not call p2pdma paths when generating it.

> Also, AFAICS, translating BAR Address to VRAM Address can only be
> done by the Xe driver bound to PF because it has access to provisioning
> data. In other words, vfio-pci would not be able to share any other
> address other than the BAR Address because it wouldn't know how to
> translate it to VRAM Address.

If you have a vfio varient driver then the VF vfio driver could call
the Xe driver to create a suitable dmabuf using the private
addressing. This is probably what is required here if this is what you
are trying to do.

> > No, don't, it is completely wrong to mess with ACS flags for the
> > problem you are trying to solve.

> But I am not messing with any ACS flags here. I am just adding a quirk to
> sidestep the ACS enforcement check given that the PF to VF access does
> not involve the PCIe fabric in this case.

Which is completely wrong. These are all based on fabric capability,
not based on code in drivers to wrongly "translate" the dma_addr_t.

Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Jason,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
> > > In this case messing with ACS is completely wrong. If the intention is
> > > to convay a some kind of "private" address representing the physical
> > > VRAM then you need to use a DMABUF mechanism to do that, not
> deliver a
> > > P2P address that the other side cannot access.
> 
> > I think using a PCI BAR Address works just fine in this case because the Xe
> > driver bound to PF on the Host can easily determine that it belongs to one
> > of the VFs and translate it into VRAM Address.
> 
> That isn't how the P2P or ACS mechansim works in Linux, it is about
> the actual address used for DMA.
Right, but this is not dealing with P2P DMA access between two random,
unrelated devices. Instead, this is a special situation involving a GPU PF
trying to access the VRAM of a VF that it provisioned and holds a reference
on (note that the backing object for VF's VRAM is pinned by Xe on Host
as part of resource provisioning). But it gets treated as regular P2P DMA
because the exporters rely on pci_p2pdma_distance() or
pci_p2pdma_map_type() to determine P2P compatibility.

In other words, I am trying to look at this problem differently: how can the
PF be allowed to access the VF's resource that it provisioned, particularly
when the VF itself requests the PF to access it and when a hardware path
(via PCIe fabric) is not required/supported or doesn't exist at all?

Furthermore, note that on a server system with a whitelisted PCIe upstream
bridge, this quirk would not be needed at all as pci_p2pdma_map_type()
would not have failed and this would have been a purely Xe driver specific
problem to solve that would have required just the translation logic and no
further changes anywhere. But my goal is to fix it across systems like
workstations/desktops that do not typically have whitelisted PCIe upstream
bridges.

> 
> You can't translate a dma_addr_t to anything in the Xe PF driver
> anyhow, once it goes through the IOMMU the necessary information is lost.
Well, I already tested this path (via IOMMU, with your earlier vfio-pci +
dmabuf patch that used dma_map_resource() and also with Leon's latest
version) and found that I could still do the translation in the Xe PF driver
after first calling iommu_iova_to_phys().

> This is a fundamentally broken design to dma map something and
> then try to reverse engineer the dma_addr_t back to something with
> meaning.
IIUC, I don't think this is a new or radical idea. I think the concept is slightly
similar to using bounce buffers to address hardware DMA limitations except
that there are no memory copies and the CPU is not involved. And, I don't see
any other way to do this because I don't believe the exporter can provide a
DMA address that the importer can use directly without any translation, which
seems unavoidable in this case.

> 
> > > Christian told me dmabuf has such a private address mechanism, so
> > > please figure out a way to use it..
> >
> > Even if such as a mechanism exists, we still need a way to prevent
> > pci_p2pdma_map_type() from failing when invoked by the exporter (vfio-
> pci).
> > Does it make sense to move this quirk into the exporter?
> 
> When you export a private address through dmabuf the VFIO exporter
> will not call p2pdma paths when generating it.
I have cc'd Christian and Simona. Hopefully, they can help explain how
the dmabuf private address mechanism can be used to address my
use-case. And, I sincerely hope that it will work, otherwise I don't see
any viable path forward for what I am trying to do other than using this
quirk and translation. Note that the main reason why I am doing this
is because I am seeing at-least ~35% performance gain when running
light 3D/Gfx workloads.

> 
> > Also, AFAICS, translating BAR Address to VRAM Address can only be
> > done by the Xe driver bound to PF because it has access to provisioning
> > data. In other words, vfio-pci would not be able to share any other
> > address other than the BAR Address because it wouldn't know how to
> > translate it to VRAM Address.
> 
> If you have a vfio varient driver then the VF vfio driver could call
> the Xe driver to create a suitable dmabuf using the private
> addressing. This is probably what is required here if this is what you
> are trying to do.
Could this not be done via the vendor agnostic vfio-pci (+ dmabuf) driver
instead of having to use a separate VF/vfio variant driver?

> 
> > > No, don't, it is completely wrong to mess with ACS flags for the
> > > problem you are trying to solve.
> 
> > But I am not messing with any ACS flags here. I am just adding a quirk to
> > sidestep the ACS enforcement check given that the PF to VF access does
> > not involve the PCIe fabric in this case.
> 
> Which is completely wrong. These are all based on fabric capability,
> not based on code in drivers to wrongly "translate" the dma_addr_t.
I am not sure why you consider translation to be wrong in this case
given that it is done by a trusted entity (Xe PF driver) that is bound to
the GPU PF and provisioned the resource that it is trying to access.
What limitations do you see with this approach?

Also, the quirk being added in this patch is indeed meant to address a
specific case (GPU PF to VF access) to workaround a potential hardware
limitation (non-existence of a direct PF to VF DMA access path via the
PCIe fabric). Isn't that one of the main ideas behind using quirks -- to
address hardware limitations?

Thanks,
Vivek

> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

Hi guys,

On 22.09.25 08:59, Kasireddy, Vivek wrote:
> Hi Jason,
> 
>> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
>> functions of Intel GPUs
>>
>> On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
>>>> In this case messing with ACS is completely wrong. If the intention is
>>>> to convay a some kind of "private" address representing the physical
>>>> VRAM then you need to use a DMABUF mechanism to do that, not
>> deliver a
>>>> P2P address that the other side cannot access.
>>
>>> I think using a PCI BAR Address works just fine in this case because the Xe
>>> driver bound to PF on the Host can easily determine that it belongs to one
>>> of the VFs and translate it into VRAM Address.
>>
>> That isn't how the P2P or ACS mechansim works in Linux, it is about
>> the actual address used for DMA.
> Right, but this is not dealing with P2P DMA access between two random,
> unrelated devices. Instead, this is a special situation involving a GPU PF
> trying to access the VRAM of a VF that it provisioned and holds a reference
> on (note that the backing object for VF's VRAM is pinned by Xe on Host
> as part of resource provisioning). But it gets treated as regular P2P DMA
> because the exporters rely on pci_p2pdma_distance() or
> pci_p2pdma_map_type() to determine P2P compatibility.
> 
> In other words, I am trying to look at this problem differently: how can the
> PF be allowed to access the VF's resource that it provisioned, particularly
> when the VF itself requests the PF to access it and when a hardware path
> (via PCIe fabric) is not required/supported or doesn't exist at all?

Well what exactly is happening here? You have a PF assigned to the host and a VF passed through to a guest, correct?

And now the PF (from the host side) wants to access a BAR of the VF?

Regards,
Christian.

> 
> Furthermore, note that on a server system with a whitelisted PCIe upstream
> bridge, this quirk would not be needed at all as pci_p2pdma_map_type()
> would not have failed and this would have been a purely Xe driver specific
> problem to solve that would have required just the translation logic and no
> further changes anywhere. But my goal is to fix it across systems like
> workstations/desktops that do not typically have whitelisted PCIe upstream
> bridges.
> 
>>
>> You can't translate a dma_addr_t to anything in the Xe PF driver
>> anyhow, once it goes through the IOMMU the necessary information is lost.
> Well, I already tested this path (via IOMMU, with your earlier vfio-pci +
> dmabuf patch that used dma_map_resource() and also with Leon's latest
> version) and found that I could still do the translation in the Xe PF driver
> after first calling iommu_iova_to_phys().
> 
>> This is a fundamentally broken design to dma map something and
>> then try to reverse engineer the dma_addr_t back to something with
>> meaning.
> IIUC, I don't think this is a new or radical idea. I think the concept is slightly
> similar to using bounce buffers to address hardware DMA limitations except
> that there are no memory copies and the CPU is not involved. And, I don't see
> any other way to do this because I don't believe the exporter can provide a
> DMA address that the importer can use directly without any translation, which
> seems unavoidable in this case.
> 
>>
>>>> Christian told me dmabuf has such a private address mechanism, so
>>>> please figure out a way to use it..
>>>
>>> Even if such as a mechanism exists, we still need a way to prevent
>>> pci_p2pdma_map_type() from failing when invoked by the exporter (vfio-
>> pci).
>>> Does it make sense to move this quirk into the exporter?
>>
>> When you export a private address through dmabuf the VFIO exporter
>> will not call p2pdma paths when generating it.
> I have cc'd Christian and Simona. Hopefully, they can help explain how
> the dmabuf private address mechanism can be used to address my
> use-case. And, I sincerely hope that it will work, otherwise I don't see
> any viable path forward for what I am trying to do other than using this
> quirk and translation. Note that the main reason why I am doing this
> is because I am seeing at-least ~35% performance gain when running
> light 3D/Gfx workloads.
> 
>>
>>> Also, AFAICS, translating BAR Address to VRAM Address can only be
>>> done by the Xe driver bound to PF because it has access to provisioning
>>> data. In other words, vfio-pci would not be able to share any other
>>> address other than the BAR Address because it wouldn't know how to
>>> translate it to VRAM Address.
>>
>> If you have a vfio varient driver then the VF vfio driver could call
>> the Xe driver to create a suitable dmabuf using the private
>> addressing. This is probably what is required here if this is what you
>> are trying to do.
> Could this not be done via the vendor agnostic vfio-pci (+ dmabuf) driver
> instead of having to use a separate VF/vfio variant driver?
> 
>>
>>>> No, don't, it is completely wrong to mess with ACS flags for the
>>>> problem you are trying to solve.
>>
>>> But I am not messing with any ACS flags here. I am just adding a quirk to
>>> sidestep the ACS enforcement check given that the PF to VF access does
>>> not involve the PCIe fabric in this case.
>>
>> Which is completely wrong. These are all based on fabric capability,
>> not based on code in drivers to wrongly "translate" the dma_addr_t.
> I am not sure why you consider translation to be wrong in this case
> given that it is done by a trusted entity (Xe PF driver) that is bound to
> the GPU PF and provisioned the resource that it is trying to access.
> What limitations do you see with this approach?
> 
> Also, the quirk being added in this patch is indeed meant to address a
> specific case (GPU PF to VF access) to workaround a potential hardware
> limitation (non-existence of a direct PF to VF DMA access path via the
> PCIe fabric). Isn't that one of the main ideas behind using quirks -- to
> address hardware limitations?
> 
> Thanks,
> Vivek
> 
>>
>> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 22, 2025 at 06:59:10AM +0000, Kasireddy, Vivek wrote:

> > You can't translate a dma_addr_t to anything in the Xe PF driver
> > anyhow, once it goes through the IOMMU the necessary information is lost.
> Well, I already tested this path (via IOMMU, with your earlier vfio-pci +
> dmabuf patch that used dma_map_resource() and also with Leon's latest
> version) and found that I could still do the translation in the Xe PF driver
> after first calling iommu_iova_to_phys().

I would NAK any driver doing something so hacky. You are approaching
this completely wrong to abuse things like this.

> that there are no memory copies and the CPU is not involved. And, I don't see
> any other way to do this because I don't believe the exporter can provide a
> DMA address that the importer can use directly without any translation, which
> seems unavoidable in this case.

This is sadly how dmabuf is designed, please talk to Christain to
figure out how to exchage the right kind of address.

> use-case. And, I sincerely hope that it will work, otherwise I don't see
> any viable path forward for what I am trying to do other than using this
> quirk and translation. 

You will not get a quirk.

> PCIe fabric). Isn't that one of the main ideas behind using quirks -- to
> address hardware limitations?

This is not a hardware limitation. You are using DMABUF wrong, writing
hacks into the PF driver and then trying to make up a fake ACS quirk
:(

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:

> Well what exactly is happening here? You have a PF assigned to the
> host and a VF passed through to a guest, correct?
>
> And now the PF (from the host side) wants to access a BAR of the VF?

Not quite.

It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
the VF can access some VRAM.

They want to get a DMABUF handle for a bit of the VF's reachable VRAM
that the PF can import and use through it's own funciton.

The use of the VF's BAR in this series is an ugly hack. The PF never
actually uses the VF BAR, it just hackily converts the dma_addr_t back
to CPU physical and figures out where it is in the VRAM pool and then
uses a PF centric address for it.

All they want is either the actual VRAM address or the CPU physical.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 22.09.25 14:20, Jason Gunthorpe wrote:
> On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> 
>> Well what exactly is happening here? You have a PF assigned to the
>> host and a VF passed through to a guest, correct?
>>
>> And now the PF (from the host side) wants to access a BAR of the VF?
> 
> Not quite.
> 
> It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> the VF can access some VRAM.
> 
> They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> that the PF can import and use through it's own funciton.

Yeah, where's the problem? We do that all the time.

> The use of the VF's BAR in this series is an ugly hack. The PF never
> actually uses the VF BAR, it just hackily converts the dma_addr_t back
> to CPU physical and figures out where it is in the VRAM pool and then
> uses a PF centric address for it.

Oh my, please absolutely don't do that!

If you have a device internal connection then you need special handling between your PF and VF driver.

But I still don't have the full picture of who is using what here, e.g. who is providing the DMA-buf handle and who is using it?

Regards,
Christian.

> 
> All they want is either the actual VRAM address or the CPU physical.
> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 22, 2025 at 02:25:15PM +0200, Christian König wrote:
> On 22.09.25 14:20, Jason Gunthorpe wrote:
> > On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> > 
> >> Well what exactly is happening here? You have a PF assigned to the
> >> host and a VF passed through to a guest, correct?
> >>
> >> And now the PF (from the host side) wants to access a BAR of the VF?
> > 
> > Not quite.
> > 
> > It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> > the VF can access some VRAM.
> > 
> > They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> > that the PF can import and use through it's own funciton.
> 
> Yeah, where's the problem? We do that all the time.

Well this is the problem:

> > The use of the VF's BAR in this series is an ugly hack. The PF never
> > actually uses the VF BAR, it just hackily converts the dma_addr_t back
> > to CPU physical and figures out where it is in the VRAM pool and then
> > uses a PF centric address for it.
> 
> Oh my, please absolutely don't do that!

Great.

> If you have a device internal connection then you need special
> handling between your PF and VF driver.

Generic VFIO can't do something like that, so they would need to make
a special variant VFIO driver.

> But I still don't have the full picture of who is using what here,
> e.g. who is providing the DMA-buf handle and who is using it?

Generic VFIO is the exporer, the xe driver is the importer.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 22.09.25 14:29, Jason Gunthorpe wrote:
> On Mon, Sep 22, 2025 at 02:25:15PM +0200, Christian König wrote:
>> On 22.09.25 14:20, Jason Gunthorpe wrote:
>>> On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
>>>
>>>> Well what exactly is happening here? You have a PF assigned to the
>>>> host and a VF passed through to a guest, correct?
>>>>
>>>> And now the PF (from the host side) wants to access a BAR of the VF?
>>>
>>> Not quite.
>>>
>>> It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
>>> the VF can access some VRAM.
>>>
>>> They want to get a DMABUF handle for a bit of the VF's reachable VRAM
>>> that the PF can import and use through it's own funciton.
>>
>> Yeah, where's the problem? We do that all the time.
> 
> Well this is the problem:
> 
>>> The use of the VF's BAR in this series is an ugly hack. The PF never
>>> actually uses the VF BAR, it just hackily converts the dma_addr_t back
>>> to CPU physical and figures out where it is in the VRAM pool and then
>>> uses a PF centric address for it.
>>
>> Oh my, please absolutely don't do that!
> 
> Great.
> 
>> If you have a device internal connection then you need special
>> handling between your PF and VF driver.
> 
> Generic VFIO can't do something like that, so they would need to make
> a special variant VFIO driver.
>
>> But I still don't have the full picture of who is using what here,
>> e.g. who is providing the DMA-buf handle and who is using it?
> 
> Generic VFIO is the exporer, the xe driver is the importer.

Why in the world is the exporter the generic VFIO driver?

At least on AMD GPUs when you want to have a DMA-buf for a specific part of the VFs resources then you ask the hypervisor driver managing the PF for that and not the VFIO driver.

Background is that the VFIO only sees the BARs of the VF and that in turn is usually only a window giving access to a fraction of the resources assigned to the VF. In other words VF BAR is 256MiB in size while 4GiB of VRAM is assigned to the VF (for example).

With that design you don't run into issues with PCIe P2P in the first place. On the other hand when you want to do PCIe P2P to the VF BAR than asking the VFIO driver does make perfect sense, but that doesn't seem to be the use case here.

Regards,
Christian.

> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 22, 2025 at 03:20:49PM +0200, Christian König wrote:

> At least on AMD GPUs when you want to have a DMA-buf for a specific
> part of the VFs resources then you ask the hypervisor driver
> managing the PF for that and not the VFIO driver.

Having a UAPI on the PF to give DMABUFs for arbitary VRAM seems
security exciting. I'd probably want to insist the calling process
prove to the PF driver that it also has access to the VF.

Having the VF create the DMABUF is one way to do that, but I imagine
there are other options.

But sure, if you can solve, or ignore, the security proof it makes a
lot more sense.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 22.09.25 15:27, Jason Gunthorpe wrote:
> On Mon, Sep 22, 2025 at 03:20:49PM +0200, Christian König wrote:
> 
>> At least on AMD GPUs when you want to have a DMA-buf for a specific
>> part of the VFs resources then you ask the hypervisor driver
>> managing the PF for that and not the VFIO driver.
> 
> Having a UAPI on the PF to give DMABUFs for arbitary VRAM seems
> security exciting. I'd probably want to insist the calling process
> prove to the PF driver that it also has access to the VF.

Good point. In our use case it's the userspace hypervisor component (running as root) talking to the kernel hypervisor driver and it is only used to collect very specific crash information.

> Having the VF create the DMABUF is one way to do that, but I imagine
> there are other options.

Well how does the guest communicate to the host which parts of the VRAM should be exposed as DMA-buf in the first place?

> 
> But sure, if you can solve, or ignore, the security proof it makes a
> lot more sense.

I mean what I'm still missing is the whole picture. E.g. what is the reason why you want a DMA-buf of portions of the VFs resource on the host in the first place?

Is that for postmortem crash analysis? Providing some kind of service to the guest? Something completely different?

Regards,
Christian.

> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Mon, Sep 22, 2025 at 03:57:02PM +0200, Christian König wrote:

> Is that for postmortem crash analysis? Providing some kind of
> service to the guest? Something completely different?

From the cover letter:

 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
 costly roundtrip to System RAM. And, weston-simple-egl can now
 achieve ~59 FPS while running with Gnome Wayland in the Guest VM.
 
Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Jason,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> 
> > Well what exactly is happening here? You have a PF assigned to the
> > host and a VF passed through to a guest, correct?
> >
> > And now the PF (from the host side) wants to access a BAR of the VF?
> 
> Not quite.
> 
> It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> the VF can access some VRAM.
> 
> They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> that the PF can import and use through it's own funciton.
> 
> The use of the VF's BAR in this series is an ugly hack.
IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
to never expose VRAM Addresses and instead have BAR addresses as DMA
addresses when exporting dmabufs to other devices. Here is the relevant code
snippet in Xe:
                phys_addr_t phys = cursor.start + xe_vram_region_io_start(tile->mem.vram);             
                size_t size = min_t(u64, cursor.size, SZ_2G);                         
                dma_addr_t addr;                                                      
                                                                                      
                addr = dma_map_resource(dev, phys, size, dir,                         
                                        DMA_ATTR_SKIP_CPU_SYNC);

And, here is the one in amdgpu:
        for_each_sgtable_sg((*sgt), sg, i) {
                phys_addr_t phys = cursor.start + adev->gmc.aper_base;
                unsigned long size = min(cursor.size, AMDGPU_MAX_SG_SEGMENT_SIZE);
                dma_addr_t addr;

                addr = dma_map_resource(dev, phys, size, dir,
                                        DMA_ATTR_SKIP_CPU_SYNC);

And, AFAICS, most of these drivers don't see use the BAR addresses directly
if they import a dmabuf that they exported earlier and instead do this:

        if (dma_buf->ops == &xe_dmabuf_ops) {
                obj = dma_buf->priv;
                if (obj->dev == dev &&
                    !XE_TEST_ONLY(test && test->force_different_devices)) {
                        /*
                         * Importing dmabuf exported from out own gem increases
                         * refcount on gem itself instead of f_count of dmabuf.
                         */
                        drm_gem_object_get(obj);
                        return obj;
                }
        }

>The PF never actually uses the VF BAR
That's because the PF can't use it directly, most likely due to hardware limitations.

>it just hackily converts the dma_addr_t back
> to CPU physical and figures out where it is in the VRAM pool and then
> uses a PF centric address for it.
> 
> All they want is either the actual VRAM address or the CPU physical.
The problem here is that the CPU physical (aka BAR Address) is only
usable by the CPU. Since the GPU PF only understands VRAM addresses,
the current exporter (vfio-pci) or any VF/VFIO variant driver cannot provide
the VRAM addresses that the GPU PF can use directly because they do not
have access to the provisioning data.

However, it is possible that if vfio-pci or a VF/VFIO variant driver had access
to the VF's provisioning data, then it might be able to create a dmabuf with
VRAM addresses that the PF can use directly. But I am not sure if exposing
provisioning data to VFIO drivers is ok from a security standpoint or not.

Thanks,
Vivek

> 
> Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Christian,

> 
> Hi guys,
> 
> On 22.09.25 08:59, Kasireddy, Vivek wrote:
> > Hi Jason,
> >
> >> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for
> device
> >> functions of Intel GPUs
> >>
> >> On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
> >>>> In this case messing with ACS is completely wrong. If the intention is
> >>>> to convay a some kind of "private" address representing the physical
> >>>> VRAM then you need to use a DMABUF mechanism to do that, not
> >> deliver a
> >>>> P2P address that the other side cannot access.
> >>
> >>> I think using a PCI BAR Address works just fine in this case because the
> Xe
> >>> driver bound to PF on the Host can easily determine that it belongs to
> one
> >>> of the VFs and translate it into VRAM Address.
> >>
> >> That isn't how the P2P or ACS mechansim works in Linux, it is about
> >> the actual address used for DMA.
> > Right, but this is not dealing with P2P DMA access between two random,
> > unrelated devices. Instead, this is a special situation involving a GPU PF
> > trying to access the VRAM of a VF that it provisioned and holds a
> reference
> > on (note that the backing object for VF's VRAM is pinned by Xe on Host
> > as part of resource provisioning). But it gets treated as regular P2P DMA
> > because the exporters rely on pci_p2pdma_distance() or
> > pci_p2pdma_map_type() to determine P2P compatibility.
> >
> > In other words, I am trying to look at this problem differently: how can the
> > PF be allowed to access the VF's resource that it provisioned, particularly
> > when the VF itself requests the PF to access it and when a hardware path
> > (via PCIe fabric) is not required/supported or doesn't exist at all?
> 
> Well what exactly is happening here? You have a PF assigned to the host
> and a VF passed through to a guest, correct?
Yes, correct.

> 
> And now the PF (from the host side) wants to access a BAR of the VF?
Yes, that is indeed the use-case, except that the PF cannot access a buffer
located in VF's VRAM portion via the BAR because this path is likely not
supported by our hardware. Therefore, my proposal (via this patch series)
is to translate the BAR addresses into VRAM addresses in Xe driver (on the Host).

Here are some more details about the use-case (copied from an earlier reply
to Jason):
- Xe Graphics driver, bound to GPU PF on the Host provisions its resources
including VRAM among all the VFs.

- A GPU VF device is bound to vfio-pci and assigned to a Linux VM which
is launched via Qemu.

- The Xe Graphics driver running inside the Linux VM creates a buffer
(Gnome Wayland compositor's framebuffer) in the VF's portion (or share)
of the VRAM and this buffer is shared with Qemu. Qemu then requests
vfio-pci driver to create a dmabuf associated with this buffer.

- Next, Qemu (UI layer) requests the GPU PF (via the Xe driver) to import
the dmabuf (for display purposes) located in VF's portion of the VRAM. This
is where two problems occur: 

1) The exporter (vfio-pci driver in this case) calls pci_p2pdma_map_type()
to determine the mapping type (or check P2P compatibility) between both
devices (GPU VF and PF) but it fails due to the ACS enforcement check because
the PCIe upstream bridge is not whitelisted, which is a common problem on
workstations/desktops/laptops.

2) Assuming that pci_p2pdma_map_type() did not fail (likely on server systems
with whitelisted PCIe bridges), based on my experiments, the GPU PF is unable
to access the buffer located in VF's VRAM portion directly because it is represented
using PCI BAR addresses. (note that, the PCI BAR address is the DMA address
here which seems to be a common practice among GPU drivers including Xe and
Amdgpu when exporting dmabufs to other devices).

The only way this seems to be work at the moment is if the BAR addresses
are translated into VRAM addresses that the GPU PF understands (this is done
done inside Xe driver on the Host using provisioning data). Note that this buffer
is accessible by the CPU using BAR addresses but it is very slow.

So, in summary, given that the GPU PF does not need to use PCIe fabric in
order to access the buffer located in GPU VF's portion of the VRAM in this
use-case, I figured adding a quirk (to not enforce ACS check) would solve 1)
and implementing the BAR to VRAM address translation in Xe driver on the
Host would solve 2) above.

Also, Jason suggested that using dmabuf private address mechanism would
help with my use-case. Could you please share details about how it can be
used here?

Thanks,
Vivek

> 
> Regards,
> Christian.
> 
> >
> > Furthermore, note that on a server system with a whitelisted PCIe
> upstream
> > bridge, this quirk would not be needed at all as pci_p2pdma_map_type()
> > would not have failed and this would have been a purely Xe driver specific
> > problem to solve that would have required just the translation logic and
> no
> > further changes anywhere. But my goal is to fix it across systems like
> > workstations/desktops that do not typically have whitelisted PCIe
> upstream
> > bridges.
> >
> >>
> >> You can't translate a dma_addr_t to anything in the Xe PF driver
> >> anyhow, once it goes through the IOMMU the necessary information is
> lost.
> > Well, I already tested this path (via IOMMU, with your earlier vfio-pci +
> > dmabuf patch that used dma_map_resource() and also with Leon's latest
> > version) and found that I could still do the translation in the Xe PF driver
> > after first calling iommu_iova_to_phys().
> >
> >> This is a fundamentally broken design to dma map something and
> >> then try to reverse engineer the dma_addr_t back to something with
> >> meaning.
> > IIUC, I don't think this is a new or radical idea. I think the concept is
> slightly
> > similar to using bounce buffers to address hardware DMA limitations
> except
> > that there are no memory copies and the CPU is not involved. And, I don't
> see
> > any other way to do this because I don't believe the exporter can provide
> a
> > DMA address that the importer can use directly without any translation,
> which
> > seems unavoidable in this case.
> >
> >>
> >>>> Christian told me dmabuf has such a private address mechanism, so
> >>>> please figure out a way to use it..
> >>>
> >>> Even if such as a mechanism exists, we still need a way to prevent
> >>> pci_p2pdma_map_type() from failing when invoked by the exporter
> (vfio-
> >> pci).
> >>> Does it make sense to move this quirk into the exporter?
> >>
> >> When you export a private address through dmabuf the VFIO exporter
> >> will not call p2pdma paths when generating it.
> > I have cc'd Christian and Simona. Hopefully, they can help explain how
> > the dmabuf private address mechanism can be used to address my
> > use-case. And, I sincerely hope that it will work, otherwise I don't see
> > any viable path forward for what I am trying to do other than using this
> > quirk and translation. Note that the main reason why I am doing this
> > is because I am seeing at-least ~35% performance gain when running
> > light 3D/Gfx workloads.
> >
> >>
> >>> Also, AFAICS, translating BAR Address to VRAM Address can only be
> >>> done by the Xe driver bound to PF because it has access to provisioning
> >>> data. In other words, vfio-pci would not be able to share any other
> >>> address other than the BAR Address because it wouldn't know how to
> >>> translate it to VRAM Address.
> >>
> >> If you have a vfio varient driver then the VF vfio driver could call
> >> the Xe driver to create a suitable dmabuf using the private
> >> addressing. This is probably what is required here if this is what you
> >> are trying to do.
> > Could this not be done via the vendor agnostic vfio-pci (+ dmabuf) driver
> > instead of having to use a separate VF/vfio variant driver?
> >
> >>
> >>>> No, don't, it is completely wrong to mess with ACS flags for the
> >>>> problem you are trying to solve.
> >>
> >>> But I am not messing with any ACS flags here. I am just adding a quirk to
> >>> sidestep the ACS enforcement check given that the PF to VF access does
> >>> not involve the PCIe fabric in this case.
> >>
> >> Which is completely wrong. These are all based on fabric capability,
> >> not based on code in drivers to wrongly "translate" the dma_addr_t.
> > I am not sure why you consider translation to be wrong in this case
> > given that it is done by a trusted entity (Xe PF driver) that is bound to
> > the GPU PF and provisioned the resource that it is trying to access.
> > What limitations do you see with this approach?
> >
> > Also, the quirk being added in this patch is indeed meant to address a
> > specific case (GPU PF to VF access) to workaround a potential hardware
> > limitation (non-existence of a direct PF to VF DMA access path via the
> > PCIe fabric). Isn't that one of the main ideas behind using quirks -- to
> > address hardware limitations?
> >
> > Thanks,
> > Vivek
> >
> >>
> >> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Matthew Brost]

On Mon, Sep 22, 2025 at 11:53:06PM -0600, Kasireddy, Vivek wrote:
> Hi Jason,
> 
> > Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> > functions of Intel GPUs
> > 
> > On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> > 
> > > Well what exactly is happening here? You have a PF assigned to the
> > > host and a VF passed through to a guest, correct?
> > >
> > > And now the PF (from the host side) wants to access a BAR of the VF?
> > 
> > Not quite.
> > 
> > It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> > the VF can access some VRAM.
> > 
> > They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> > that the PF can import and use through it's own funciton.
> > 
> > The use of the VF's BAR in this series is an ugly hack.
> IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
> to never expose VRAM Addresses and instead have BAR addresses as DMA
> addresses when exporting dmabufs to other devices. Here is the relevant code
> snippet in Xe:
>                 phys_addr_t phys = cursor.start + xe_vram_region_io_start(tile->mem.vram);             
>                 size_t size = min_t(u64, cursor.size, SZ_2G);                         
>                 dma_addr_t addr;                                                      
>                                                                                       
>                 addr = dma_map_resource(dev, phys, size, dir,                         
>                                         DMA_ATTR_SKIP_CPU_SYNC);
> 
> And, here is the one in amdgpu:
>         for_each_sgtable_sg((*sgt), sg, i) {
>                 phys_addr_t phys = cursor.start + adev->gmc.aper_base;
>                 unsigned long size = min(cursor.size, AMDGPU_MAX_SG_SEGMENT_SIZE);
>                 dma_addr_t addr;
> 
>                 addr = dma_map_resource(dev, phys, size, dir,
>                                         DMA_ATTR_SKIP_CPU_SYNC);
> 

I've read through this thread—Jason, correct me if I'm wrong—but I
believe what you're suggesting is that instead of using PCIe P2P
(dma_map_resource) to communicate the VF's VRAM offset to the PF, we
should teach dma-buf to natively understand a VF's VRAM offset. I don't
think this is currently built into dma-buf, but it probably should be,
as it could benefit other use cases as well (e.g., UALink, NVLink,
etc.).

In both examples above, the PCIe P2P fabric is used for communication,
whereas in the VF→PF case, it's only using the PCIe P2P address to
extract the VF's VRAM offset, rather than serving as a communication
path. I believe that's Jason's objection. Again, Jason, correct me if
I'm misunderstanding here.

Assuming I'm understanding Jason's comments correctly, I tend to agree
with him.

> And, AFAICS, most of these drivers don't see use the BAR addresses directly
> if they import a dmabuf that they exported earlier and instead do this:
> 
>         if (dma_buf->ops == &xe_dmabuf_ops) {
>                 obj = dma_buf->priv;
>                 if (obj->dev == dev &&
>                     !XE_TEST_ONLY(test && test->force_different_devices)) {
>                         /*
>                          * Importing dmabuf exported from out own gem increases
>                          * refcount on gem itself instead of f_count of dmabuf.
>                          */
>                         drm_gem_object_get(obj);
>                         return obj;
>                 }
>         }

This code won't be triggered on the VF→PF path, as obj->dev == dev will
fail.

> 
> >The PF never actually uses the VF BAR
> That's because the PF can't use it directly, most likely due to hardware limitations.
> 
> >it just hackily converts the dma_addr_t back
> > to CPU physical and figures out where it is in the VRAM pool and then
> > uses a PF centric address for it.
> > 
> > All they want is either the actual VRAM address or the CPU physical.
> The problem here is that the CPU physical (aka BAR Address) is only
> usable by the CPU. Since the GPU PF only understands VRAM addresses,
> the current exporter (vfio-pci) or any VF/VFIO variant driver cannot provide
> the VRAM addresses that the GPU PF can use directly because they do not
> have access to the provisioning data.
>

Right, we need to provide the offset within the VRAM provisioning, which
the PF can resolve to a physical address based on the provisioning data.
The series already does this—the problem is how the VF provides
this offset. It shouldn't be a P2P address, but rather a native
dma-buf-provided offset that everyone involved in the attachment
understands.
 
> However, it is possible that if vfio-pci or a VF/VFIO variant driver had access
> to the VF's provisioning data, then it might be able to create a dmabuf with
> VRAM addresses that the PF can use directly. But I am not sure if exposing
> provisioning data to VFIO drivers is ok from a security standpoint or not.
> 

I'd prefer to leave the provisioning data to the PF if possible. I
haven't fully wrapped my head around the flow yet, but it should be
feasible for the VF → VFIO → PF path to pass along the initial VF
scatter-gather (SG) list in the dma-buf, which includes VF-specific
PFNs. The PF can then use this, along with its provisioning information,
to resolve the physical address.

Matt

> Thanks,
> Vivek
> 
> > 
> > Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Matthew Brost]

On Mon, Sep 22, 2025 at 11:25:47PM -0700, Matthew Brost wrote:
> On Mon, Sep 22, 2025 at 11:53:06PM -0600, Kasireddy, Vivek wrote:
> > Hi Jason,
> > 
> > > Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> > > functions of Intel GPUs
> > > 
> > > On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
> > > 
> > > > Well what exactly is happening here? You have a PF assigned to the
> > > > host and a VF passed through to a guest, correct?
> > > >
> > > > And now the PF (from the host side) wants to access a BAR of the VF?
> > > 
> > > Not quite.
> > > 
> > > It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
> > > the VF can access some VRAM.
> > > 
> > > They want to get a DMABUF handle for a bit of the VF's reachable VRAM
> > > that the PF can import and use through it's own funciton.
> > > 
> > > The use of the VF's BAR in this series is an ugly hack.
> > IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
> > to never expose VRAM Addresses and instead have BAR addresses as DMA
> > addresses when exporting dmabufs to other devices. Here is the relevant code
> > snippet in Xe:
> >                 phys_addr_t phys = cursor.start + xe_vram_region_io_start(tile->mem.vram);             
> >                 size_t size = min_t(u64, cursor.size, SZ_2G);                         
> >                 dma_addr_t addr;                                                      
> >                                                                                       
> >                 addr = dma_map_resource(dev, phys, size, dir,                         
> >                                         DMA_ATTR_SKIP_CPU_SYNC);
> > 
> > And, here is the one in amdgpu:
> >         for_each_sgtable_sg((*sgt), sg, i) {
> >                 phys_addr_t phys = cursor.start + adev->gmc.aper_base;
> >                 unsigned long size = min(cursor.size, AMDGPU_MAX_SG_SEGMENT_SIZE);
> >                 dma_addr_t addr;
> > 
> >                 addr = dma_map_resource(dev, phys, size, dir,
> >                                         DMA_ATTR_SKIP_CPU_SYNC);
> > 
> 
> I've read through this thread—Jason, correct me if I'm wrong—but I
> believe what you're suggesting is that instead of using PCIe P2P
> (dma_map_resource) to communicate the VF's VRAM offset to the PF, we
> should teach dma-buf to natively understand a VF's VRAM offset. I don't
> think this is currently built into dma-buf, but it probably should be,
> as it could benefit other use cases as well (e.g., UALink, NVLink,
> etc.).
> 
> In both examples above, the PCIe P2P fabric is used for communication,
> whereas in the VF→PF case, it's only using the PCIe P2P address to
> extract the VF's VRAM offset, rather than serving as a communication
> path. I believe that's Jason's objection. Again, Jason, correct me if
> I'm misunderstanding here.
> 
> Assuming I'm understanding Jason's comments correctly, I tend to agree
> with him.
> 
> > And, AFAICS, most of these drivers don't see use the BAR addresses directly
> > if they import a dmabuf that they exported earlier and instead do this:
> > 
> >         if (dma_buf->ops == &xe_dmabuf_ops) {

Sorry - double reply but the above check would also fail on the VF→PF path.

Matt

> >                 obj = dma_buf->priv;
> >                 if (obj->dev == dev &&
> >                     !XE_TEST_ONLY(test && test->force_different_devices)) {
> >                         /*
> >                          * Importing dmabuf exported from out own gem increases
> >                          * refcount on gem itself instead of f_count of dmabuf.
> >                          */
> >                         drm_gem_object_get(obj);
> >                         return obj;
> >                 }
> >         }
> 
> This code won't be triggered on the VF→PF path, as obj->dev == dev will
> fail.
> 
> > 
> > >The PF never actually uses the VF BAR
> > That's because the PF can't use it directly, most likely due to hardware limitations.
> > 
> > >it just hackily converts the dma_addr_t back
> > > to CPU physical and figures out where it is in the VRAM pool and then
> > > uses a PF centric address for it.
> > > 
> > > All they want is either the actual VRAM address or the CPU physical.
> > The problem here is that the CPU physical (aka BAR Address) is only
> > usable by the CPU. Since the GPU PF only understands VRAM addresses,
> > the current exporter (vfio-pci) or any VF/VFIO variant driver cannot provide
> > the VRAM addresses that the GPU PF can use directly because they do not
> > have access to the provisioning data.
> >
> 
> Right, we need to provide the offset within the VRAM provisioning, which
> the PF can resolve to a physical address based on the provisioning data.
> The series already does this—the problem is how the VF provides
> this offset. It shouldn't be a P2P address, but rather a native
> dma-buf-provided offset that everyone involved in the attachment
> understands.
>  
> > However, it is possible that if vfio-pci or a VF/VFIO variant driver had access
> > to the VF's provisioning data, then it might be able to create a dmabuf with
> > VRAM addresses that the PF can use directly. But I am not sure if exposing
> > provisioning data to VFIO drivers is ok from a security standpoint or not.
> > 
> 
> I'd prefer to leave the provisioning data to the PF if possible. I
> haven't fully wrapped my head around the flow yet, but it should be
> feasible for the VF → VFIO → PF path to pass along the initial VF
> scatter-gather (SG) list in the dma-buf, which includes VF-specific
> PFNs. The PF can then use this, along with its provisioning information,
> to resolve the physical address.
> 
> Matt
> 
> > Thanks,
> > Vivek
> > 
> > > 
> > > Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

Hi guys,

trying to not let the mail thread branch to much, I'm just replying on the newest mail.

Please let me know if I missed some question.

On 23.09.25 08:44, Matthew Brost wrote:
> On Mon, Sep 22, 2025 at 11:25:47PM -0700, Matthew Brost wrote:
>> On Mon, Sep 22, 2025 at 11:53:06PM -0600, Kasireddy, Vivek wrote:
>>> Hi Jason,
>>>
>>>> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
>>>> functions of Intel GPUs
>>>>
>>>> On Mon, Sep 22, 2025 at 01:22:49PM +0200, Christian König wrote:
>>>>
>>>>> Well what exactly is happening here? You have a PF assigned to the
>>>>> host and a VF passed through to a guest, correct?
>>>>>
>>>>> And now the PF (from the host side) wants to access a BAR of the VF?
>>>>
>>>> Not quite.
>>>>
>>>> It is a GPU so it has a pool of VRAM. The PF can access all VRAM and
>>>> the VF can access some VRAM.
>>>>
>>>> They want to get a DMABUF handle for a bit of the VF's reachable VRAM
>>>> that the PF can import and use through it's own funciton.
>>>>
>>>> The use of the VF's BAR in this series is an ugly hack.
>>> IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
>>> to never expose VRAM Addresses and instead have BAR addresses as DMA
>>> addresses when exporting dmabufs to other devices. Here is the relevant code
>>> snippet in Xe:

That sounds a bit mixed up. There are two different concepts which can be used here:

1. Driver exposing DMA addresses to PCIe BARs.

For example this is done by amdgpu and XE to give other drivers access to MMIO registers as well as VRAM when it isn't backed by struct pages.

2. Drivers short cutting internally access paths.

This is used in amdgpu and a lot of other drivers when it finds that an DMA-buf was exported by itself.

For example the ISP driver part of amdgpu provides the V4L2 interface and when we interchange a DMA-buf with it we recognize that it is actually the same device we work with.

Currently the implementation is based on approach #1, but as far as I can see what's actually needed is approach #2.

>> I've read through this thread—Jason, correct me if I'm wrong—but I
>> believe what you're suggesting is that instead of using PCIe P2P
>> (dma_map_resource) to communicate the VF's VRAM offset to the PF, we
>> should teach dma-buf to natively understand a VF's VRAM offset. I don't
>> think this is currently built into dma-buf, but it probably should be,
>> as it could benefit other use cases as well (e.g., UALink, NVLink,
>> etc.).
>>
>> In both examples above, the PCIe P2P fabric is used for communication,
>> whereas in the VF→PF case, it's only using the PCIe P2P address to
>> extract the VF's VRAM offset, rather than serving as a communication
>> path. I believe that's Jason's objection. Again, Jason, correct me if
>> I'm misunderstanding here.
>>
>> Assuming I'm understanding Jason's comments correctly, I tend to agree
>> with him.

Yeah, agree that here is just an extremely ugly hack.

>>>> The PF never actually uses the VF BAR
>>> That's because the PF can't use it directly, most likely due to hardware limitations.
>>>
>>>> it just hackily converts the dma_addr_t back
>>>> to CPU physical and figures out where it is in the VRAM pool and then
>>>> uses a PF centric address for it.
>>>>
>>>> All they want is either the actual VRAM address or the CPU physical.
>>> The problem here is that the CPU physical (aka BAR Address) is only
>>> usable by the CPU. Since the GPU PF only understands VRAM addresses,
>>> the current exporter (vfio-pci) or any VF/VFIO variant driver cannot provide
>>> the VRAM addresses that the GPU PF can use directly because they do not
>>> have access to the provisioning data.
>>>
>>
>> Right, we need to provide the offset within the VRAM provisioning, which
>> the PF can resolve to a physical address based on the provisioning data.
>> The series already does this—the problem is how the VF provides
>> this offset. It shouldn't be a P2P address, but rather a native
>> dma-buf-provided offset that everyone involved in the attachment
>> understands.

What you can do is to either export the DMA-buf from the driver who feels responsible for the PF directly (that's what we do in amdgpu because the VRAM is actually not fully accessible through the BAR).

Or you could extend the VFIO driver with a private interface for the PF to exposing the offsets into the BAR instead of the DMA addresses.

>>  
>>> However, it is possible that if vfio-pci or a VF/VFIO variant driver had access
>>> to the VF's provisioning data, then it might be able to create a dmabuf with
>>> VRAM addresses that the PF can use directly. But I am not sure if exposing
>>> provisioning data to VFIO drivers is ok from a security standpoint or not.
>>>

How are those offsets into the BAR communicated from the guest to the host in the first place?

>> I'd prefer to leave the provisioning data to the PF if possible. I
>> haven't fully wrapped my head around the flow yet, but it should be
>> feasible for the VF → VFIO → PF path to pass along the initial VF
>> scatter-gather (SG) list in the dma-buf, which includes VF-specific
>> PFNs. The PF can then use this, along with its provisioning information,
>> to resolve the physical address.

Well don't put that into the sg_table but rather into an xarray or similar, but in general that's the correct idea.

Regards,
Christian.

>>
>> Matt
>>
>>> Thanks,
>>> Vivek
>>>
>>>>
>>>> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Tue, Sep 23, 2025 at 09:52:04AM +0200, Christian König wrote:
> For example the ISP driver part of amdgpu provides the V4L2
> interface and when we interchange a DMA-buf with it we recognize that
> it is actually the same device we work with.

One of the issues here is the mis-use of dma_map_resource() to create
dma_addr_t for PCI devices. This was never correct.

VFIO is using a new correct ACS aware DMA mapping API that I would
expect all the DMABUF world to slowly migrate to. This API prevents
mappings in cases that don't work in HW.

So a design where you have to DMA map something then throw away the
DMA map after doing some "shortcut" check isn't going to work.

We need some way for the importer/exporter to negotiate what kind of
address they want to exchange without forcing a dma mapping.

> >> I've read through this thread—Jason, correct me if I'm wrong—but I
> >> believe what you're suggesting is that instead of using PCIe P2P
> >> (dma_map_resource) to communicate the VF's VRAM offset to the PF, we
> >> should teach dma-buf to natively understand a VF's VRAM offset. I don't
> >> think this is currently built into dma-buf, but it probably should be,
> >> as it could benefit other use cases as well (e.g., UALink, NVLink,
> >> etc.).
> >>
> >> In both examples above, the PCIe P2P fabric is used for communication,
> >> whereas in the VF→PF case, it's only using the PCIe P2P address to
> >> extract the VF's VRAM offset, rather than serving as a communication
> >> path. I believe that's Jason's objection. Again, Jason, correct me if
> >> I'm misunderstanding here.

Yes, this is my point.

We have many cases now where a dma_addr_t is not the appropriate way
to exchange addressing information from importer/exporter and we need
more flexibility.

I also consider the KVM and iommufd use cases that must have a
phys_addr_t in this statement.

> What you can do is to either export the DMA-buf from the driver who
> feels responsible for the PF directly (that's what we do in amdgpu
> because the VRAM is actually not fully accessible through the BAR).

Again, considering security somehow as there should not be uAPI to
just give uncontrolled access to VRAM.

From a security side having the VF create the DMABUF is better as you
get that security proof that it is permitted to access the VRAM.

From this thread I think if VFIO had the negotiated option to export a
CPU phys_addr_t then the Xe PF driver can reliably convert that to a
VRAM offset.

We need to add a CPU phys_addr_t option for VFIO to iommufd and KVM
anyhow, those cases can't use dma_addr_t.

> >> I'd prefer to leave the provisioning data to the PF if possible. I
> >> haven't fully wrapped my head around the flow yet, but it should be
> >> feasible for the VF → VFIO → PF path to pass along the initial VF
> >> scatter-gather (SG) list in the dma-buf, which includes VF-specific
> >> PFNs. The PF can then use this, along with its provisioning information,
> >> to resolve the physical address.
> 
> Well don't put that into the sg_table but rather into an xarray or
> similar, but in general that's the correct idea.

Yes, please lets move away from re-using dma_addr_t to represent
things that are not created by the DMA API.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 23.09.25 14:15, Jason Gunthorpe wrote:
> On Tue, Sep 23, 2025 at 09:52:04AM +0200, Christian König wrote:
>> For example the ISP driver part of amdgpu provides the V4L2
>> interface and when we interchange a DMA-buf with it we recognize that
>> it is actually the same device we work with.
> 
> One of the issues here is the mis-use of dma_map_resource() to create
> dma_addr_t for PCI devices. This was never correct.

That is not a mis-use at all but rather exactly what dma_map_resource() was created for.

If dma_map_resource() is not ACS aware than we should add that.

> VFIO is using a new correct ACS aware DMA mapping API that I would
> expect all the DMABUF world to slowly migrate to. This API prevents
> mappings in cases that don't work in HW.
> 
> So a design where you have to DMA map something then throw away the
> DMA map after doing some "shortcut" check isn't going to work.
> 
> We need some way for the importer/exporter to negotiate what kind of
> address they want to exchange without forcing a dma mapping.

That is already in place. We don't DMA map anything in those use cases.

>>>> I've read through this thread—Jason, correct me if I'm wrong—but I
>>>> believe what you're suggesting is that instead of using PCIe P2P
>>>> (dma_map_resource) to communicate the VF's VRAM offset to the PF, we
>>>> should teach dma-buf to natively understand a VF's VRAM offset. I don't
>>>> think this is currently built into dma-buf, but it probably should be,
>>>> as it could benefit other use cases as well (e.g., UALink, NVLink,
>>>> etc.).
>>>>
>>>> In both examples above, the PCIe P2P fabric is used for communication,
>>>> whereas in the VF→PF case, it's only using the PCIe P2P address to
>>>> extract the VF's VRAM offset, rather than serving as a communication
>>>> path. I believe that's Jason's objection. Again, Jason, correct me if
>>>> I'm misunderstanding here.
> 
> Yes, this is my point.
> 
> We have many cases now where a dma_addr_t is not the appropriate way
> to exchange addressing information from importer/exporter and we need
> more flexibility.
> 
> I also consider the KVM and iommufd use cases that must have a
> phys_addr_t in this statement.

Abusing phys_addr_t is also the completely wrong approach in that moment.

When you want to communicate addresses in a device specific address space you need a device specific type for that and not abuse phys_addr_t.

>> What you can do is to either export the DMA-buf from the driver who
>> feels responsible for the PF directly (that's what we do in amdgpu
>> because the VRAM is actually not fully accessible through the BAR).
> 
> Again, considering security somehow as there should not be uAPI to
> just give uncontrolled access to VRAM.
> 
> From a security side having the VF create the DMABUF is better as you
> get that security proof that it is permitted to access the VRAM.

Well the VF is basically just a window into the HW of the PF.

The real question is where does the VFIO gets the necessary information which parts of the BAR to expose?

> From this thread I think if VFIO had the negotiated option to export a
> CPU phys_addr_t then the Xe PF driver can reliably convert that to a
> VRAM offset.
> 
> We need to add a CPU phys_addr_t option for VFIO to iommufd and KVM
> anyhow, those cases can't use dma_addr_t.

Clear NAK to using CPU phys_addr_t. This is just a horrible idea.

Regards,
Christian.

> 
>>>> I'd prefer to leave the provisioning data to the PF if possible. I
>>>> haven't fully wrapped my head around the flow yet, but it should be
>>>> feasible for the VF → VFIO → PF path to pass along the initial VF
>>>> scatter-gather (SG) list in the dma-buf, which includes VF-specific
>>>> PFNs. The PF can then use this, along with its provisioning information,
>>>> to resolve the physical address.
>>
>> Well don't put that into the sg_table but rather into an xarray or
>> similar, but in general that's the correct idea.
> 
> Yes, please lets move away from re-using dma_addr_t to represent
> things that are not created by the DMA API.
> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Tue, Sep 23, 2025 at 02:45:10PM +0200, Christian König wrote:
> On 23.09.25 14:15, Jason Gunthorpe wrote:
> > On Tue, Sep 23, 2025 at 09:52:04AM +0200, Christian König wrote:
> >> For example the ISP driver part of amdgpu provides the V4L2
> >> interface and when we interchange a DMA-buf with it we recognize that
> >> it is actually the same device we work with.
> > 
> > One of the issues here is the mis-use of dma_map_resource() to create
> > dma_addr_t for PCI devices. This was never correct.
> 
> That is not a mis-use at all but rather exactly what
> dma_map_resource() was created for.

No, it isn't this is a misunderstanding. It was created for SOC
resources only. I think HCH made this clear a number of times.

> If dma_map_resource() is not ACS aware than we should add that.

It can't be fixed with the API it has. See how the new VFIO patches
are working to understand the proposal.
 
> > We have many cases now where a dma_addr_t is not the appropriate way
> > to exchange addressing information from importer/exporter and we need
> > more flexibility.
> > 
> > I also consider the KVM and iommufd use cases that must have a
> > phys_addr_t in this statement.
> 
> Abusing phys_addr_t is also the completely wrong approach in that moment.
> 
> When you want to communicate addresses in a device specific address
> space you need a device specific type for that and not abuse
> phys_addr_t.

I'm not talking about abusing phys_addr_t, I'm talking about putting a
legitimate CPU address in there.

You can argue it is hack in Xe to reverse engineer the VRAM offset
from a CPU physical, and I would be sympathetic, but it does allow
VFIO to be general not specialized to Xe.

> The real question is where does the VFIO gets the necessary
> information which parts of the BAR to expose?

It needs a varaint driver that understands to reach into the PF parent
and extract this information.

There is a healthy amount of annoyance to building something like this.
 
> > From this thread I think if VFIO had the negotiated option to export a
> > CPU phys_addr_t then the Xe PF driver can reliably convert that to a
> > VRAM offset.
> > 
> > We need to add a CPU phys_addr_t option for VFIO to iommufd and KVM
> > anyhow, those cases can't use dma_addr_t.
> 
> Clear NAK to using CPU phys_addr_t. This is just a horrible idea.

We already talked about this, Simona agreed, we need to get
phys_addr_t optionally out of VFIO's dmabuf for a few importers. We
cannot use dma_addr_t.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 23.09.25 15:12, Jason Gunthorpe wrote:
>> When you want to communicate addresses in a device specific address
>> space you need a device specific type for that and not abuse
>> phys_addr_t.
> 
> I'm not talking about abusing phys_addr_t, I'm talking about putting a
> legitimate CPU address in there.
> 
> You can argue it is hack in Xe to reverse engineer the VRAM offset
> from a CPU physical, and I would be sympathetic, but it does allow
> VFIO to be general not specialized to Xe.

No, exactly that doesn't work for all use cases. That's why I'm pushing back so hard on using phys_addr_t or CPU addresses.

See the CPU address is only valid temporary because the VF BAR is only a window into the device memory.

This window is open as long as the CPU is using it, but as soon as that is not the case any more that window might close creating tons of lifetime issues.

>> The real question is where does the VFIO gets the necessary
>> information which parts of the BAR to expose?
> 
> It needs a varaint driver that understands to reach into the PF parent
> and extract this information.
> 
> There is a healthy amount of annoyance to building something like this.
>  
>>> From this thread I think if VFIO had the negotiated option to export a
>>> CPU phys_addr_t then the Xe PF driver can reliably convert that to a
>>> VRAM offset.
>>>
>>> We need to add a CPU phys_addr_t option for VFIO to iommufd and KVM
>>> anyhow, those cases can't use dma_addr_t.
>>
>> Clear NAK to using CPU phys_addr_t. This is just a horrible idea.
> 
> We already talked about this, Simona agreed, we need to get
> phys_addr_t optionally out of VFIO's dmabuf for a few importers. We
> cannot use dma_addr_t.

Not saying that we should use dma_addr_t, but using phys_addr_t is as equally broken and I will certainly NAK any approach using this as general interface between drivers.

What Simona agreed on is exactly what I proposed as well, that you get a private interface for exactly that use case.

Regards,
Christian.

> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christoph Hellwig]

On Tue, Sep 23, 2025 at 02:45:10PM +0200, Christian König wrote:
> On 23.09.25 14:15, Jason Gunthorpe wrote:
> > On Tue, Sep 23, 2025 at 09:52:04AM +0200, Christian König wrote:
> >> For example the ISP driver part of amdgpu provides the V4L2
> >> interface and when we interchange a DMA-buf with it we recognize that
> >> it is actually the same device we work with.
> > 
> > One of the issues here is the mis-use of dma_map_resource() to create
> > dma_addr_t for PCI devices. This was never correct.
> 
> That is not a mis-use at all but rather exactly what dma_map_resource() was created for.

It isn't.  dma_map_resource was not created for PCIe P2P, and does not
work for the general case of PCIe P2P including offsets and switches.
Using it always was a big, and the drm driver maitaintainers were
constanty reminded of that and chose to ignore it with passion.

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
> On 23.09.25 15:12, Jason Gunthorpe wrote:
> >> When you want to communicate addresses in a device specific address
> >> space you need a device specific type for that and not abuse
> >> phys_addr_t.
> > 
> > I'm not talking about abusing phys_addr_t, I'm talking about putting a
> > legitimate CPU address in there.
> > 
> > You can argue it is hack in Xe to reverse engineer the VRAM offset
> > from a CPU physical, and I would be sympathetic, but it does allow
> > VFIO to be general not specialized to Xe.
> 
> No, exactly that doesn't work for all use cases. That's why I'm
> pushing back so hard on using phys_addr_t or CPU addresses.
> 
> See the CPU address is only valid temporary because the VF BAR is
> only a window into the device memory.

I know, generally yes.

But there should be no way that a VFIO VF driver in the hypervisor
knows what is currently mapped to the VF's BAR. The only way I can
make sense of what Xe is doing here is if the VF BAR is a static
aperture of the VRAM..

Would be nice to know the details.
 
> What Simona agreed on is exactly what I proposed as well, that you
> get a private interface for exactly that use case.

A "private" interface to exchange phys_addr_t between at least
VFIO/KVM/iommufd - sure no complaint with that.

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 23.09.25 15:38, Jason Gunthorpe wrote:
> On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
>> On 23.09.25 15:12, Jason Gunthorpe wrote:
>>>> When you want to communicate addresses in a device specific address
>>>> space you need a device specific type for that and not abuse
>>>> phys_addr_t.
>>>
>>> I'm not talking about abusing phys_addr_t, I'm talking about putting a
>>> legitimate CPU address in there.
>>>
>>> You can argue it is hack in Xe to reverse engineer the VRAM offset
>>> from a CPU physical, and I would be sympathetic, but it does allow
>>> VFIO to be general not specialized to Xe.
>>
>> No, exactly that doesn't work for all use cases. That's why I'm
>> pushing back so hard on using phys_addr_t or CPU addresses.
>>
>> See the CPU address is only valid temporary because the VF BAR is
>> only a window into the device memory.
> 
> I know, generally yes.
> 
> But there should be no way that a VFIO VF driver in the hypervisor
> knows what is currently mapped to the VF's BAR. The only way I can
> make sense of what Xe is doing here is if the VF BAR is a static
> aperture of the VRAM..
> 
> Would be nice to know the details.

Yeah, that's why i asked how VFIO gets the information which parts of the it's BAR should be part of the DMA-buf?

That would be really interesting to know.

Regards,
Christian.

>  
>> What Simona agreed on is exactly what I proposed as well, that you
>> get a private interface for exactly that use case.
> 
> A "private" interface to exchange phys_addr_t between at least
> VFIO/KVM/iommufd - sure no complaint with that.
> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Matthew Brost]

On Tue, Sep 23, 2025 at 03:48:59PM +0200, Christian König wrote:
> On 23.09.25 15:38, Jason Gunthorpe wrote:
> > On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
> >> On 23.09.25 15:12, Jason Gunthorpe wrote:
> >>>> When you want to communicate addresses in a device specific address
> >>>> space you need a device specific type for that and not abuse
> >>>> phys_addr_t.
> >>>
> >>> I'm not talking about abusing phys_addr_t, I'm talking about putting a
> >>> legitimate CPU address in there.
> >>>
> >>> You can argue it is hack in Xe to reverse engineer the VRAM offset
> >>> from a CPU physical, and I would be sympathetic, but it does allow
> >>> VFIO to be general not specialized to Xe.
> >>
> >> No, exactly that doesn't work for all use cases. That's why I'm
> >> pushing back so hard on using phys_addr_t or CPU addresses.
> >>
> >> See the CPU address is only valid temporary because the VF BAR is
> >> only a window into the device memory.
> > 
> > I know, generally yes.
> > 
> > But there should be no way that a VFIO VF driver in the hypervisor
> > knows what is currently mapped to the VF's BAR. The only way I can
> > make sense of what Xe is doing here is if the VF BAR is a static
> > aperture of the VRAM..
> > 
> > Would be nice to know the details.
> 
> Yeah, that's why i asked how VFIO gets the information which parts of the it's BAR should be part of the DMA-buf?
> 

Vivek can confirm for sure, but I believe the VF knows the size of its
VRAM space and simply wants to pass along the offset and allocation
order within that space. The PF knows where the VF's VRAM is located in
the BAR, and the combination of the VF base offset and the individual
allocation offset is what gets programmed into the PF page tables.

> That would be really interesting to know.
> 
> Regards,
> Christian.
> 
> >  
> >> What Simona agreed on is exactly what I proposed as well, that you
> >> get a private interface for exactly that use case.

Do you have a link to the conversation with Simona? I'd lean towards a
kernel-wide generic interface if possible.

Regarding phys_addr_t vs. dma_addr_t, I don't have a strong opinion. But
what about using an array of unsigned long with the order encoded
similarly to HMM PFNs? Drivers can interpret the address portion of the
data based on their individual use cases.

Also, to make this complete—do you think we'd need to teach TTM to
understand this new type of dma-buf, like we do for SG list dma-bufs? It
would seem a bit pointless if we just had to convert this new dma-buf
back into an SG list to pass it along to TTM.

The scope of this seems considerably larger than the original series. It
would be good for all stakeholders to reach an agreement so Vivek can
move forward.

Matt

> > 
> > A "private" interface to exchange phys_addr_t between at least
> > VFIO/KVM/iommufd - sure no complaint with that.
> > 
> > Jason
> 

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Christian,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On 23.09.25 15:38, Jason Gunthorpe wrote:
> > On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
> >> On 23.09.25 15:12, Jason Gunthorpe wrote:
> >>>> When you want to communicate addresses in a device specific address
> >>>> space you need a device specific type for that and not abuse
> >>>> phys_addr_t.
> >>>
> >>> I'm not talking about abusing phys_addr_t, I'm talking about putting a
> >>> legitimate CPU address in there.
> >>>
> >>> You can argue it is hack in Xe to reverse engineer the VRAM offset
> >>> from a CPU physical, and I would be sympathetic, but it does allow
> >>> VFIO to be general not specialized to Xe.
> >>
> >> No, exactly that doesn't work for all use cases. That's why I'm
> >> pushing back so hard on using phys_addr_t or CPU addresses.
> >>
> >> See the CPU address is only valid temporary because the VF BAR is
> >> only a window into the device memory.
> >
> > I know, generally yes.
> >
> > But there should be no way that a VFIO VF driver in the hypervisor
> > knows what is currently mapped to the VF's BAR. The only way I can
> > make sense of what Xe is doing here is if the VF BAR is a static
> > aperture of the VRAM..
> >
> > Would be nice to know the details.
> 
> Yeah, that's why i asked how VFIO gets the information which parts of the
> it's BAR should be part of the DMA-buf?
> 
> That would be really interesting to know.
As Jason guessed, we are relying on the GPU VF being a Large BAR
device here. In other words, as you suggested, this will not work if the
VF BAR size is not as big as its actual VRAM portion. We can certainly add
this check but we have not seen either the GPU PF or VF getting detected
as Small BAR devices in various test environments.

So, given the above, once a VF device is bound to vfio-pci driver and
assigned to a Guest VM (launched via Qemu), Qemu's vfio layer maps
all the VF's resources including the BARs. This mapping info (specifically HVA)
is leveraged (by Qemu) to identity the offset at which the Guest VM's buffer
is located (in the BAR) and this info is then provided to vfio-pci kernel driver
which finally creates the dmabuf (with BAR Addresses).

Thanks,
Vivek

> 
> Regards,
> Christian.
> 
> >
> >> What Simona agreed on is exactly what I proposed as well, that you
> >> get a private interface for exactly that use case.
> >
> > A "private" interface to exchange phys_addr_t between at least
> > VFIO/KVM/iommufd - sure no complaint with that.
> >
> > Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 24.09.25 08:50, Kasireddy, Vivek wrote:
> Hi Christian,
> 
>> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
>> functions of Intel GPUs
>>
>> On 23.09.25 15:38, Jason Gunthorpe wrote:
>>> On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
>>>> On 23.09.25 15:12, Jason Gunthorpe wrote:
>>>>>> When you want to communicate addresses in a device specific address
>>>>>> space you need a device specific type for that and not abuse
>>>>>> phys_addr_t.
>>>>>
>>>>> I'm not talking about abusing phys_addr_t, I'm talking about putting a
>>>>> legitimate CPU address in there.
>>>>>
>>>>> You can argue it is hack in Xe to reverse engineer the VRAM offset
>>>>> from a CPU physical, and I would be sympathetic, but it does allow
>>>>> VFIO to be general not specialized to Xe.
>>>>
>>>> No, exactly that doesn't work for all use cases. That's why I'm
>>>> pushing back so hard on using phys_addr_t or CPU addresses.
>>>>
>>>> See the CPU address is only valid temporary because the VF BAR is
>>>> only a window into the device memory.
>>>
>>> I know, generally yes.
>>>
>>> But there should be no way that a VFIO VF driver in the hypervisor
>>> knows what is currently mapped to the VF's BAR. The only way I can
>>> make sense of what Xe is doing here is if the VF BAR is a static
>>> aperture of the VRAM..
>>>
>>> Would be nice to know the details.
>>
>> Yeah, that's why i asked how VFIO gets the information which parts of the
>> it's BAR should be part of the DMA-buf?
>>
>> That would be really interesting to know.
> As Jason guessed, we are relying on the GPU VF being a Large BAR
> device here. In other words, as you suggested, this will not work if the
> VF BAR size is not as big as its actual VRAM portion. We can certainly add
> this check but we have not seen either the GPU PF or VF getting detected
> as Small BAR devices in various test environments.
> 
> So, given the above, once a VF device is bound to vfio-pci driver and
> assigned to a Guest VM (launched via Qemu), Qemu's vfio layer maps
> all the VF's resources including the BARs. This mapping info (specifically HVA)
> is leveraged (by Qemu) to identity the offset at which the Guest VM's buffer
> is located (in the BAR) and this info is then provided to vfio-pci kernel driver
> which finally creates the dmabuf (with BAR Addresses).

In that case I strongly suggest to add a private DMA-buf interface for the DMA-bufs exported by vfio-pci which returns which BAR and offset the DMA-buf represents.

Ideally using the same structure Qemu used to provide the offset to the vfio-pci driver, but not a must have.

This way the driver for the GPU PF (XE) can leverage this interface, validates that the DMA-buf comes from a VF it feels responsible for and do the math to figure out in which parts of the VRAM needs to be accessed to scanout the picture.

This way this private vfio-pci interface can also be used by iommufd for example.

Regards,
Christian.

> 
> Thanks,
> Vivek
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>>> What Simona agreed on is exactly what I proposed as well, that you
>>>> get a private interface for exactly that use case.
>>>
>>> A "private" interface to exchange phys_addr_t between at least
>>> VFIO/KVM/iommufd - sure no complaint with that.
>>>
>>> Jason
> 

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 24.09.25 01:02, Matthew Brost wrote:
>>>> What Simona agreed on is exactly what I proposed as well, that you
>>>> get a private interface for exactly that use case.
> 
> Do you have a link to the conversation with Simona? I'd lean towards a
> kernel-wide generic interface if possible.

Oh, finding that exactly mail is tricky.

IIRC she wrote something along the lines of "this should be done in a vfio/iommufd interface", but maybe my memory is a bit selective.

We can of course still leverage the DMA-buf lifetime, synchronization and other functionalities.

But this is so vfio specific that this is not going to fly as general DMA-buf interface I think.

> Regarding phys_addr_t vs. dma_addr_t, I don't have a strong opinion. But
> what about using an array of unsigned long with the order encoded
> similarly to HMM PFNs? Drivers can interpret the address portion of the
> data based on their individual use cases.

That's basically what I had in mind for replacing the sg_table.

> Also, to make this complete—do you think we'd need to teach TTM to
> understand this new type of dma-buf, like we do for SG list dma-bufs? It
> would seem a bit pointless if we just had to convert this new dma-buf
> back into an SG list to pass it along to TTM.

Using an sg_table / SG list in DMA-buf and TTM was a bad idea to begin with. At least for amdgpu we have switched over to just have that around temporary for most use cases.

What we need is a container for efficient dma_addr_t storage (e.g. using low bits for the size/order of the area). Then iterators/cursors to go over that container.

Switching between an sg_table and that new container is then just switching out the iterators.

> The scope of this seems considerably larger than the original series. It
> would be good for all stakeholders to reach an agreement so Vivek can
> move forward.

Yeah, agree.

Regards,
Christian.

> 
> Matt
> 
>>>
>>> A "private" interface to exchange phys_addr_t between at least
>>> VFIO/KVM/iommufd - sure no complaint with that.
>>>
>>> Jason
>>

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Simon Richter]

Hi,

since I'm late to the party I'll reply to the entire thread in one go.

On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:

> I think using a PCI BAR Address works just fine in this case because the Xe
> driver bound to PF on the Host can easily determine that it belongs to one
> of the VFs and translate it into VRAM Address.

There are PCIe bridges that support address translation, and might apply
different translations for different PASIDs, so this determination would
need to walk the device tree on both guest and host in a way that does
not confer trust to the guest or allows it to gain access to resources
through race conditions.

The difficulty here is that you are building a communication mechanism
that bypasses a trust boundary in the virtualization framework, so it
becomes part of the virtualization framework. I believe we can avoid
that to some extent by exchanging handles instead of raw pointers.

I can see the point in using the dmabuf API, because it integrates well
with existing 3D APIs in userspace, although I don't quite understand
what the VK_KHR_external_memory_dma_buf extension actually does, besides
defining a flag bit -- it seems the heavy lifting is done by the
VK_KHR_external_memory_fd extension anyway. But yes, we probably want
the interface to be compatible to existing sharing APIs on the host side
at least, to allow the guest's "on-screen" images to be easily imported.

There is some potential for a shortcut here as well, giving these
buffers directly to the host's desktop compositor instead of having an
application react to updates by copying the data from the area shared
with the VF to the area shared between the application and the
compositor -- that would also be a reason to remain close to the
existing interface.

It's not entirely necessary for this interface to be a dma_buf, as long
as we have a conversion between a file descriptor and a BO.  On the
other hand, it may be desirable to allow re-exporting it as a dma_buf if
we want to access it from another device as well.

I'm not sure that is a likely use case though, even the horrible
contraption I'm building here that has a Thunderbolt device send data
directly to VRAM does not require that, because the guest would process
the data and then send a different buffer to the host. Still would be
nice for completeness.

The other thing that seems to be looming on the horizon is that dma_buf
is too limited for VRAM buffers, because once it's imported, it is
pinned as well, but we'd like to keep it moveable (there was another
thread on the xe mailing list about that). That might even be more
important if we have limited BAR space, because then we might not want
to make the memory accessible through the BAR unless imported by
something that needs access through the BAR, which we've established the
main use case doesn't (because it doesn't even need any kind of access).

I think passing objects between trust domains should take the form of an
opaque handle that is not predictable, and refers to an internal data
structure with the actual parameters (so we pass these internally as
well, and avoid all the awkwardness of host and guest having different
world views. It doesn't matter if that path is slow, it should only be
used rather seldom (at VM start and when the VM changes screen
resolution).

For VM startup, we probably want to provision guest "on-screen" memory
and semaphores really early -- maybe it makes sense to just give each VF
a sensible shared mapping like 16 MB (rounded up from 2*1080p*32bit) by
default, and/or present a ROM with EFI and OpenFirmware drivers -- can
VFs do that on current hardware?

On Tue, Sep 23, 2025 at 05:53:06AM +0000, Kasireddy, Vivek wrote:

> IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
> to never expose VRAM Addresses and instead have BAR addresses as DMA
> addresses when exporting dmabufs to other devices.

Yes, because that is how the other devices access that memory.

> The problem here is that the CPU physical (aka BAR Address) is only
> usable by the CPU.

The address you receive from mapping a dma_buf for a particular device
is not a CPU physical address, even if it is identical on pretty much
all PC hardware because it is uncommon to configure the root bridge with
a translation there.

On my POWER9 machine, the situation is a bit different: a range in the
lower 4 GB is reserved for 32-bit BARs, the memory with those physical
addresses is remapped so it appears after the end of physical RAM from
the point of view of PCIe devices, and the 32 bit BARs appear at the
base of the PCIe bus (after the legacy ports).

So, as an example (reality is a bit more complex :> ) the memory map
might look like

0000000000000000..0000001fffffffff    RAM
0060000000000000..006001ffffffffff    PCIe domain 1
0060020000000000..006003ffffffffff    PCIe domain 2
...

and the phys_addr_t I get on the CPU refers to this mapping. However, a
device attached to PCIe domain 1 would see

0000000000000000..000000000000ffff    Legacy I/O in PCIe domain 1
0000000000010000..00000000000fffff    Legacy VGA mappings
0000000000100000..000000007fffffff    32-bit BARs in PCIe domain 1
0000000080000000..00000000ffffffff    RAM (accessible to 32 bit devices)
0000000100000000..0000001fffffffff    RAM (requires 64 bit addressing)
0000002000000000..000000207fffffff    RAM (CPU physical address 0..2GB)
0060000080000000..006001ffffffffff    64-bit BARs in PCIe domain 1
0060020000000000..006003ffffffffff    PCIe domain 2

This allows 32 bit devices to access other 32 bit devices on the same
bus, and (some) physical memory, but we need to sacrifice the 1:1
mapping for host memory. The actual mapping is a bit more complex,
because 64 bit BARs get mapped into the "32 bit" space to keep them
accessible for 32 bit cards in the same domain, and this would also be a
valid reason not to extend the BAR size even if we can.

The default 256 MB aperture ends up in the "32 bit" range, so unless the
BAR is resized and reallocated, the CPU and DMA addresses for the
aperture *will* differ.

So when a DMA buffer is created that ends up in the first 2 GB of RAM,
the dma_addr_t returned for this device will have 0x2000000000 added to
it, because that is the address that the device will have to use, and
DMA buffers for 32 bit devices will be taken from the 2GB..4GB range
because neither the first 2 GB nor anything beyond 4 GB are accessible
to this device.

If there is a 32 bit BAR at 0x10000000 in domain 1, then the CPU will
see it at 0x60000010000000, but mapping it from another device in the
same domain will return a dma_addr_t of 0x10000000 -- because that is
the address that is routeable in the PCIe fabric, this is the BAR
address configured into the device so it will actually respond, and the
TLP will not leave the bus because it is downstream of the root bridge,
so it does not affect the physical RAM.

Actual numbers will be different to handle even more corner cases and I
don't remember exactly how many zeroes are in each range, but you get
the idea -- and this is before we've even started creating virtual
machines with a different view of physical addresses.

On Tue, Sep 23, 2025 at 06:01:34AM +0000, Kasireddy, Vivek wrote:

> - The Xe Graphics driver running inside the Linux VM creates a buffer
> (Gnome Wayland compositor's framebuffer) in the VF's portion (or share)
> of the VRAM and this buffer is shared with Qemu. Qemu then requests
> vfio-pci driver to create a dmabuf associated with this buffer.

That's a bit late. What is EFI supposed to do?

   Simon

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Wed, Sep 24, 2025 at 06:13:56PM +0200, Simon Richter wrote:
> > The problem here is that the CPU physical (aka BAR Address) is only
> > usable by the CPU.
> 
> The address you receive from mapping a dma_buf for a particular device
> is not a CPU physical address, even if it is identical on pretty much
> all PC hardware because it is uncommon to configure the root bridge with
> a translation there.

I said already, you cannot convert from a dma_addr_t back to a
phys_addr_t. There is just no universal API for this and your examples
like PPC explain why it cannot work even if some hacks appear to be
okay on one x86 system.

I think Christian's suggestion is to pass a
(struct pci_dev *, bar index, bar offset) between dmabuf
exporter/importer

That would work for alot of use case, we could make iommufd and kvm
work with that.

The Xe PF driver could detect the vram by checking if the pci_dev * is
a VF of itself and then using its internal knowledge of the
provisioned VF BAR to compute the VRAM location.

If it is not this case then it would fall back to the normal 'exporter
does dma map' fllow.

Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Christian,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> >>
> >> On 23.09.25 15:38, Jason Gunthorpe wrote:
> >>> On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König wrote:
> >>>> On 23.09.25 15:12, Jason Gunthorpe wrote:
> >>>>>> When you want to communicate addresses in a device specific
> address
> >>>>>> space you need a device specific type for that and not abuse
> >>>>>> phys_addr_t.
> >>>>>
> >>>>> I'm not talking about abusing phys_addr_t, I'm talking about putting a
> >>>>> legitimate CPU address in there.
> >>>>>
> >>>>> You can argue it is hack in Xe to reverse engineer the VRAM offset
> >>>>> from a CPU physical, and I would be sympathetic, but it does allow
> >>>>> VFIO to be general not specialized to Xe.
> >>>>
> >>>> No, exactly that doesn't work for all use cases. That's why I'm
> >>>> pushing back so hard on using phys_addr_t or CPU addresses.
> >>>>
> >>>> See the CPU address is only valid temporary because the VF BAR is
> >>>> only a window into the device memory.
> >>>
> >>> I know, generally yes.
> >>>
> >>> But there should be no way that a VFIO VF driver in the hypervisor
> >>> knows what is currently mapped to the VF's BAR. The only way I can
> >>> make sense of what Xe is doing here is if the VF BAR is a static
> >>> aperture of the VRAM..
> >>>
> >>> Would be nice to know the details.
> >>
> >> Yeah, that's why i asked how VFIO gets the information which parts of the
> >> it's BAR should be part of the DMA-buf?
> >>
> >> That would be really interesting to know.
> > As Jason guessed, we are relying on the GPU VF being a Large BAR
> > device here. In other words, as you suggested, this will not work if the
> > VF BAR size is not as big as its actual VRAM portion. We can certainly add
> > this check but we have not seen either the GPU PF or VF getting detected
> > as Small BAR devices in various test environments.
> >
> > So, given the above, once a VF device is bound to vfio-pci driver and
> > assigned to a Guest VM (launched via Qemu), Qemu's vfio layer maps
> > all the VF's resources including the BARs. This mapping info (specifically
> HVA)
> > is leveraged (by Qemu) to identity the offset at which the Guest VM's buffer
> > is located (in the BAR) and this info is then provided to vfio-pci kernel driver
> > which finally creates the dmabuf (with BAR Addresses).
> 
> In that case I strongly suggest to add a private DMA-buf interface for the DMA-
> bufs exported by vfio-pci which returns which BAR and offset the DMA-buf
> represents.
Does this private dmabuf interface already exist or does it need to be created
from the ground up?

If it already exists, could you please share an example/reference of how you
have used it with amdgpu or other drivers?

If it doesn't exist, I was wondering if it should be based on any particular best
practices/ideas (or design patterns) that already exist in other drivers?

> 
> Ideally using the same structure Qemu used to provide the offset to the vfio-
> pci driver, but not a must have.
> 
> This way the driver for the GPU PF (XE) can leverage this interface, validates
> that the DMA-buf comes from a VF it feels responsible for and do the math to
> figure out in which parts of the VRAM needs to be accessed to scanout the
> picture.
Sounds good. This is definitely a viable path forward and it looks like we are all
in agreement with this idea.

I guess we can start exploring how to implement the private dmabuf interface
mechanism right away.

Thanks,
Vivek

> 
> This way this private vfio-pci interface can also be used by iommufd for
> example.
> 
> Regards,
> Christian.
> 
> >
> > Thanks,
> > Vivek
> >
> >>
> >> Regards,
> >> Christian.
> >>
> >>>
> >>>> What Simona agreed on is exactly what I proposed as well, that you
> >>>> get a private interface for exactly that use case.
> >>>
> >>> A "private" interface to exchange phys_addr_t between at least
> >>> VFIO/KVM/iommufd - sure no complaint with that.
> >>>
> >>> Jason
> >

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Simon,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> Hi,
> 
> since I'm late to the party I'll reply to the entire thread in one go.
> 
> On Fri, Sep 19, 2025 at 06:22:45AM +0000, Kasireddy, Vivek wrote:
> 
> > I think using a PCI BAR Address works just fine in this case because the Xe
> > driver bound to PF on the Host can easily determine that it belongs to one
> > of the VFs and translate it into VRAM Address.
> 
> There are PCIe bridges that support address translation, and might apply
> different translations for different PASIDs, so this determination would
> need to walk the device tree on both guest and host in a way that does
> not confer trust to the guest or allows it to gain access to resources
> through race conditions.
> 
> The difficulty here is that you are building a communication mechanism
> that bypasses a trust boundary in the virtualization framework, so it
> becomes part of the virtualization framework. I believe we can avoid
> that to some extent by exchanging handles instead of raw pointers.
> 
> I can see the point in using the dmabuf API, because it integrates well
> with existing 3D APIs in userspace, although I don't quite understand
> what the VK_KHR_external_memory_dma_buf extension actually does,
> besides
> defining a flag bit -- it seems the heavy lifting is done by the
> VK_KHR_external_memory_fd extension anyway. But yes, we probably want
> the interface to be compatible to existing sharing APIs on the host side
> at least, to allow the guest's "on-screen" images to be easily imported.
> 
> There is some potential for a shortcut here as well, giving these
> buffers directly to the host's desktop compositor instead of having an
> application react to updates by copying the data from the area shared
> with the VF to the area shared between the application and the
> compositor -- that would also be a reason to remain close to the
> existing interface.
> 
> It's not entirely necessary for this interface to be a dma_buf, as long
> as we have a conversion between a file descriptor and a BO.  On the
> other hand, it may be desirable to allow re-exporting it as a dma_buf if
> we want to access it from another device as well.
> 
> I'm not sure that is a likely use case though, even the horrible
> contraption I'm building here that has a Thunderbolt device send data
> directly to VRAM does not require that, because the guest would process
> the data and then send a different buffer to the host. Still would be
> nice for completeness.
> 
> The other thing that seems to be looming on the horizon is that dma_buf
> is too limited for VRAM buffers, because once it's imported, it is
> pinned as well, but we'd like to keep it moveable (there was another
> thread on the xe mailing list about that). That might even be more
> important if we have limited BAR space, because then we might not want
> to make the memory accessible through the BAR unless imported by
> something that needs access through the BAR, which we've established the
> main use case doesn't (because it doesn't even need any kind of access).
> 
> I think passing objects between trust domains should take the form of an
> opaque handle that is not predictable, and refers to an internal data
> structure with the actual parameters (so we pass these internally as
> well, and avoid all the awkwardness of host and guest having different
> world views. It doesn't matter if that path is slow, it should only be
> used rather seldom (at VM start and when the VM changes screen
> resolution).
> 
> For VM startup, we probably want to provision guest "on-screen" memory
> and semaphores really early -- maybe it makes sense to just give each VF
> a sensible shared mapping like 16 MB (rounded up from 2*1080p*32bit) by
> default, and/or present a ROM with EFI and OpenFirmware drivers -- can
> VFs do that on current hardware?
> 
> On Tue, Sep 23, 2025 at 05:53:06AM +0000, Kasireddy, Vivek wrote:
> 
> > IIUC, it is a common practice among GPU drivers including Xe and Amdgpu
> > to never expose VRAM Addresses and instead have BAR addresses as DMA
> > addresses when exporting dmabufs to other devices.
> 
> Yes, because that is how the other devices access that memory.
> 
> > The problem here is that the CPU physical (aka BAR Address) is only
> > usable by the CPU.
> 
> The address you receive from mapping a dma_buf for a particular device
> is not a CPU physical address, even if it is identical on pretty much
> all PC hardware because it is uncommon to configure the root bridge with
> a translation there.
> 
> On my POWER9 machine, the situation is a bit different: a range in the
> lower 4 GB is reserved for 32-bit BARs, the memory with those physical
> addresses is remapped so it appears after the end of physical RAM from
> the point of view of PCIe devices, and the 32 bit BARs appear at the
> base of the PCIe bus (after the legacy ports).
> 
> So, as an example (reality is a bit more complex :> ) the memory map
> might look like
> 
> 0000000000000000..0000001fffffffff    RAM
> 0060000000000000..006001ffffffffff    PCIe domain 1
> 0060020000000000..006003ffffffffff    PCIe domain 2
> ...
> 
> and the phys_addr_t I get on the CPU refers to this mapping. However, a
> device attached to PCIe domain 1 would see
> 
> 0000000000000000..000000000000ffff    Legacy I/O in PCIe domain 1
> 0000000000010000..00000000000fffff    Legacy VGA mappings
> 0000000000100000..000000007fffffff    32-bit BARs in PCIe domain 1
> 0000000080000000..00000000ffffffff    RAM (accessible to 32 bit devices)
> 0000000100000000..0000001fffffffff    RAM (requires 64 bit addressing)
> 0000002000000000..000000207fffffff    RAM (CPU physical address 0..2GB)
> 0060000080000000..006001ffffffffff    64-bit BARs in PCIe domain 1
> 0060020000000000..006003ffffffffff    PCIe domain 2
> 
> This allows 32 bit devices to access other 32 bit devices on the same
> bus, and (some) physical memory, but we need to sacrifice the 1:1
> mapping for host memory. The actual mapping is a bit more complex,
> because 64 bit BARs get mapped into the "32 bit" space to keep them
> accessible for 32 bit cards in the same domain, and this would also be a
> valid reason not to extend the BAR size even if we can.
> 
> The default 256 MB aperture ends up in the "32 bit" range, so unless the
> BAR is resized and reallocated, the CPU and DMA addresses for the
> aperture *will* differ.
> 
> So when a DMA buffer is created that ends up in the first 2 GB of RAM,
> the dma_addr_t returned for this device will have 0x2000000000 added to
> it, because that is the address that the device will have to use, and
> DMA buffers for 32 bit devices will be taken from the 2GB..4GB range
> because neither the first 2 GB nor anything beyond 4 GB are accessible
> to this device.
> 
> If there is a 32 bit BAR at 0x10000000 in domain 1, then the CPU will
> see it at 0x60000010000000, but mapping it from another device in the
> same domain will return a dma_addr_t of 0x10000000 -- because that is
> the address that is routeable in the PCIe fabric, this is the BAR
> address configured into the device so it will actually respond, and the
> TLP will not leave the bus because it is downstream of the root bridge,
> so it does not affect the physical RAM.
> 
> Actual numbers will be different to handle even more corner cases and I
> don't remember exactly how many zeroes are in each range, but you get
> the idea -- and this is before we've even started creating virtual
> machines with a different view of physical addresses.
Thank you for taking the time to explain in detail how the memory map and
PCI addressing mechanism works.

> 
> On Tue, Sep 23, 2025 at 06:01:34AM +0000, Kasireddy, Vivek wrote:
> 
> > - The Xe Graphics driver running inside the Linux VM creates a buffer
> > (Gnome Wayland compositor's framebuffer) in the VF's portion (or share)
> > of the VRAM and this buffer is shared with Qemu. Qemu then requests
> > vfio-pci driver to create a dmabuf associated with this buffer.
> 
> That's a bit late. What is EFI supposed to do?
If I understand your question correctly, what happens is the Guest VM's
EFI/BIOS Boot/Kernel messages are all displayed via virtio-vga (which is
included by default?) if it is added to the VM. And, the VF's VRAM does not
get used until Gnome/Mutter compositor starts. So, until this point, all
buffers are created from Guest VM's system memory only.

Thanks,
Vivek

> 
>    Simon

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Thomas Hellström]

On Thu, 2025-09-25 at 03:56 +0000, Kasireddy, Vivek wrote:
> Hi Christian,
> 
> > Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for
> > device
> > functions of Intel GPUs
> > 
> > > > 
> > > > On 23.09.25 15:38, Jason Gunthorpe wrote:
> > > > > On Tue, Sep 23, 2025 at 03:28:53PM +0200, Christian König
> > > > > wrote:
> > > > > > On 23.09.25 15:12, Jason Gunthorpe wrote:
> > > > > > > > When you want to communicate addresses in a device
> > > > > > > > specific
> > address
> > > > > > > > space you need a device specific type for that and not
> > > > > > > > abuse
> > > > > > > > phys_addr_t.
> > > > > > > 
> > > > > > > I'm not talking about abusing phys_addr_t, I'm talking
> > > > > > > about putting a
> > > > > > > legitimate CPU address in there.
> > > > > > > 
> > > > > > > You can argue it is hack in Xe to reverse engineer the
> > > > > > > VRAM offset
> > > > > > > from a CPU physical, and I would be sympathetic, but it
> > > > > > > does allow
> > > > > > > VFIO to be general not specialized to Xe.
> > > > > > 
> > > > > > No, exactly that doesn't work for all use cases. That's why
> > > > > > I'm
> > > > > > pushing back so hard on using phys_addr_t or CPU addresses.
> > > > > > 
> > > > > > See the CPU address is only valid temporary because the VF
> > > > > > BAR is
> > > > > > only a window into the device memory.
> > > > > 
> > > > > I know, generally yes.
> > > > > 
> > > > > But there should be no way that a VFIO VF driver in the
> > > > > hypervisor
> > > > > knows what is currently mapped to the VF's BAR. The only way
> > > > > I can
> > > > > make sense of what Xe is doing here is if the VF BAR is a
> > > > > static
> > > > > aperture of the VRAM..
> > > > > 
> > > > > Would be nice to know the details.
> > > > 
> > > > Yeah, that's why i asked how VFIO gets the information which
> > > > parts of the
> > > > it's BAR should be part of the DMA-buf?
> > > > 
> > > > That would be really interesting to know.
> > > As Jason guessed, we are relying on the GPU VF being a Large BAR
> > > device here. In other words, as you suggested, this will not work
> > > if the
> > > VF BAR size is not as big as its actual VRAM portion. We can
> > > certainly add
> > > this check but we have not seen either the GPU PF or VF getting
> > > detected
> > > as Small BAR devices in various test environments.
> > > 
> > > So, given the above, once a VF device is bound to vfio-pci driver
> > > and
> > > assigned to a Guest VM (launched via Qemu), Qemu's vfio layer
> > > maps
> > > all the VF's resources including the BARs. This mapping info
> > > (specifically
> > HVA)
> > > is leveraged (by Qemu) to identity the offset at which the Guest
> > > VM's buffer
> > > is located (in the BAR) and this info is then provided to vfio-
> > > pci kernel driver
> > > which finally creates the dmabuf (with BAR Addresses).
> > 
> > In that case I strongly suggest to add a private DMA-buf interface
> > for the DMA-
> > bufs exported by vfio-pci which returns which BAR and offset the
> > DMA-buf
> > represents.

@Christian, Is what you're referring to here the "dma_buf private
interconnect" we've been discussing previously, now only between vfio-
pci and any interested importers instead of private to a known exporter
and importer?

If so I have a POC I can post as an RFC on a way to negotiate such an
interconnect.

> Does this private dmabuf interface already exist or does it need to
> be created
> from the ground up?
> 
> If it already exists, could you please share an example/reference of
> how you
> have used it with amdgpu or other drivers?
> 
> If it doesn't exist, I was wondering if it should be based on any
> particular best
> practices/ideas (or design patterns) that already exist in other
> drivers?

@Vivek, another question: Also on the guest side we're exporting dma-
mapped adresses that are imported and somehow decoded by the guest
virtio-gpu driver? Is something similar needed there?

Also how would the guest side VF driver know that what is assumed to be
a PF on the same device is actually a PF on the same device and not a
completely different device with another driver? (In which case I
assume it would like to export a system dma-buf)?

Thanks,
Thomas



> 
> > 
> > Ideally using the same structure Qemu used to provide the offset to
> > the vfio-
> > pci driver, but not a must have.
> > 
> > This way the driver for the GPU PF (XE) can leverage this
> > interface, validates
> > that the DMA-buf comes from a VF it feels responsible for and do
> > the math to
> > figure out in which parts of the VRAM needs to be accessed to
> > scanout the
> > picture.
> Sounds good. This is definitely a viable path forward and it looks
> like we are all
> in agreement with this idea.
> 
> I guess we can start exploring how to implement the private dmabuf
> interface
> mechanism right away.
> 
> Thanks,
> Vivek
> 
> > 
> > This way this private vfio-pci interface can also be used by
> > iommufd for
> > example.
> > 
> > Regards,
> > Christian.
> > 
> > > 
> > > Thanks,
> > > Vivek
> > > 
> > > > 
> > > > Regards,
> > > > Christian.
> > > > 
> > > > > 
> > > > > > What Simona agreed on is exactly what I proposed as well,
> > > > > > that you
> > > > > > get a private interface for exactly that use case.
> > > > > 
> > > > > A "private" interface to exchange phys_addr_t between at
> > > > > least
> > > > > VFIO/KVM/iommufd - sure no complaint with that.
> > > > > 
> > > > > Jason
> > > 
> 

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Christian König]

On 25.09.25 12:51, Thomas Hellström wrote:
>>> In that case I strongly suggest to add a private DMA-buf interface
>>> for the DMA-
>>> bufs exported by vfio-pci which returns which BAR and offset the
>>> DMA-buf
>>> represents.
> 
> @Christian, Is what you're referring to here the "dma_buf private
> interconnect" we've been discussing previously, now only between vfio-
> pci and any interested importers instead of private to a known exporter
> and importer?
> 
> If so I have a POC I can post as an RFC on a way to negotiate such an
> interconnect.

I was just about to write something up as well, but feel free to go ahead if you already have something.

>> Does this private dmabuf interface already exist or does it need to
>> be created
>> from the ground up?

Every driver which supports both exporting and importing DMA-buf has code to detect when somebody tries to re-import a buffer previously exported from the same device.

Now some drivers like amdgpu and I think XE as well also detect if the buffer is from another device handled by the same driver which potentially have private interconnects (XGMI or similar).

See function amdgpu_dmabuf_is_xgmi_accessible() in amdgpu_dma_buf.c for an example.

>> If it already exists, could you please share an example/reference of
>> how you
>> have used it with amdgpu or other drivers?

Well what's new is that we need to do this between two drivers unreleated to each other.

As far as I know previously that was all inside AMD drivers for example, while in this case vfio is a common vendor agnostic driver.

So we should probably make sure to get that right and vendor agnostic etc....

>> If it doesn't exist, I was wondering if it should be based on any
>> particular best
>> practices/ideas (or design patterns) that already exist in other
>> drivers?
> 
> @Vivek, another question: Also on the guest side we're exporting dma-
> mapped adresses that are imported and somehow decoded by the guest
> virtio-gpu driver? Is something similar needed there?
> 
> Also how would the guest side VF driver know that what is assumed to be
> a PF on the same device is actually a PF on the same device and not a
> completely different device with another driver? (In which case I
> assume it would like to export a system dma-buf)?

Another question is how is lifetime handled? E.g. does the guest know that a DMA-buf exists for it's BAR area?

Regards,
Christian.

> 
> Thanks,
> Thomas
> 
> 
> 
>>
>>>
>>> Ideally using the same structure Qemu used to provide the offset to
>>> the vfio-
>>> pci driver, but not a must have.
>>>
>>> This way the driver for the GPU PF (XE) can leverage this
>>> interface, validates
>>> that the DMA-buf comes from a VF it feels responsible for and do
>>> the math to
>>> figure out in which parts of the VRAM needs to be accessed to
>>> scanout the
>>> picture.
>> Sounds good. This is definitely a viable path forward and it looks
>> like we are all
>> in agreement with this idea.
>>
>> I guess we can start exploring how to implement the private dmabuf
>> interface
>> mechanism right away.
>>
>> Thanks,
>> Vivek
>>
>>>
>>> This way this private vfio-pci interface can also be used by
>>> iommufd for
>>> example.
>>>
>>> Regards,
>>> Christian.
>>>
>>>>
>>>> Thanks,
>>>> Vivek
>>>>
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>>
>>>>>>> What Simona agreed on is exactly what I proposed as well,
>>>>>>> that you
>>>>>>> get a private interface for exactly that use case.
>>>>>>
>>>>>> A "private" interface to exchange phys_addr_t between at
>>>>>> least
>>>>>> VFIO/KVM/iommufd - sure no complaint with that.
>>>>>>
>>>>>> Jason
>>>>
>>
> 

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Thomas Hellström]

On Thu, 2025-09-25 at 13:28 +0200, Christian König wrote:
> On 25.09.25 12:51, Thomas Hellström wrote:
> > > > In that case I strongly suggest to add a private DMA-buf
> > > > interface
> > > > for the DMA-
> > > > bufs exported by vfio-pci which returns which BAR and offset
> > > > the
> > > > DMA-buf
> > > > represents.
> > 
> > @Christian, Is what you're referring to here the "dma_buf private
> > interconnect" we've been discussing previously, now only between
> > vfio-
> > pci and any interested importers instead of private to a known
> > exporter
> > and importer?
> > 
> > If so I have a POC I can post as an RFC on a way to negotiate such
> > an
> > interconnect.
> 
> I was just about to write something up as well, but feel free to go
> ahead if you already have something.

Just posted a POC. It might be that you have better ideas, though.


/Thomas

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Thu, Sep 25, 2025 at 03:11:50PM +0200, Thomas Hellström wrote:
> On Thu, 2025-09-25 at 13:28 +0200, Christian König wrote:
> > On 25.09.25 12:51, Thomas Hellström wrote:
> > > > > In that case I strongly suggest to add a private DMA-buf
> > > > > interface
> > > > > for the DMA-
> > > > > bufs exported by vfio-pci which returns which BAR and offset
> > > > > the
> > > > > DMA-buf
> > > > > represents.
> > > 
> > > @Christian, Is what you're referring to here the "dma_buf private
> > > interconnect" we've been discussing previously, now only between
> > > vfio-
> > > pci and any interested importers instead of private to a known
> > > exporter
> > > and importer?
> > > 
> > > If so I have a POC I can post as an RFC on a way to negotiate such
> > > an
> > > interconnect.
> > 
> > I was just about to write something up as well, but feel free to go
> > ahead if you already have something.
> 
> Just posted a POC. It might be that you have better ideas, though.

I think is also needs an API that is not based on scatterlist. Please
lets not push a private interconnect address through the scatterlist
dma_addr_t!

Assuming that you imagine we'd define some global well known
interconnect

'struct blah pci_bar_interconnect {..}'

And if that is negotiated then the non-scatterlist communication would
give the (struct pci_dev *, bar index, bar offset) list?

I think this could solve the kvm/iommufd problems at least!

Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Thomas Hellström]

On Thu, 2025-09-25 at 10:33 -0300, Jason Gunthorpe wrote:
> On Thu, Sep 25, 2025 at 03:11:50PM +0200, Thomas Hellström wrote:
> > On Thu, 2025-09-25 at 13:28 +0200, Christian König wrote:
> > > On 25.09.25 12:51, Thomas Hellström wrote:
> > > > > > In that case I strongly suggest to add a private DMA-buf
> > > > > > interface
> > > > > > for the DMA-
> > > > > > bufs exported by vfio-pci which returns which BAR and
> > > > > > offset
> > > > > > the
> > > > > > DMA-buf
> > > > > > represents.
> > > > 
> > > > @Christian, Is what you're referring to here the "dma_buf
> > > > private
> > > > interconnect" we've been discussing previously, now only
> > > > between
> > > > vfio-
> > > > pci and any interested importers instead of private to a known
> > > > exporter
> > > > and importer?
> > > > 
> > > > If so I have a POC I can post as an RFC on a way to negotiate
> > > > such
> > > > an
> > > > interconnect.
> > > 
> > > I was just about to write something up as well, but feel free to
> > > go
> > > ahead if you already have something.
> > 
> > Just posted a POC. It might be that you have better ideas, though.
> 
> I think is also needs an API that is not based on scatterlist. Please
> lets not push a private interconnect address through the scatterlist
> dma_addr_t!

I think that needs to be defined per interconnect, choosing a data
structure that suits best. Although I find it reasonable to mandate
dma_addr_t or scatterlists to *not* be used.

This merely focuses on the interconnect negotiation itself.

> 
> Assuming that you imagine we'd define some global well known
> interconnect
> 
> 'struct blah pci_bar_interconnect {..}'
> 
> And if that is negotiated then the non-scatterlist communication
> would
> give the (struct pci_dev *, bar index, bar offset) list?

Yes something like that. Although I think perhaps the dev + bar index
might be part of the negotiation, so that it is rejected if the
importer feels that there is no implied PF + VF interconnect. Then the
list would be reduced to only the offset.

Still I think Vivek would be better to figure the exact negotiation and
data structure out.
 
/Thomas

> 
> I think this could solve the kvm/iommufd problems at least!
> 
> Jason

Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Jason Gunthorpe]

On Thu, Sep 25, 2025 at 05:40:25PM +0200, Thomas Hellström wrote:
> > I think is also needs an API that is not based on scatterlist. Please
> > lets not push a private interconnect address through the scatterlist
> > dma_addr_t!
> 
> I think that needs to be defined per interconnect, choosing a data
> structure that suits best. Although I find it reasonable to mandate
> dma_addr_t or scatterlists to *not* be used.

Can you include some sketch of how that would look? And cc me please
on future versions :)

> > Assuming that you imagine we'd define some global well known
> > interconnect
> > 
> > 'struct blah pci_bar_interconnect {..}'
> > 
> > And if that is negotiated then the non-scatterlist communication
> > would
> > give the (struct pci_dev *, bar index, bar offset) list?
> 
> Yes something like that. Although I think perhaps the dev + bar index
> might be part of the negotiation, so that it is rejected if the
> importer feels that there is no implied PF + VF interconnect. Then the
> list would be reduced to only the offset.

I'm also happy if the list is just a list of bar offsets for a single
bar and the pci_dev/bar index is discovered by the importer before
getting the list.

That's probably a better API design anyhow since building the list
just to check the pci_dev is wasteful.

In this case a simple vmap of bar offset / len pairs would be nice and
easy place to start.

Jason

RE: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device functions of Intel GPUs

[Kasireddy, Vivek]

Hi Christian, Thomas,

> Subject: Re: [PATCH v4 1/5] PCI/P2PDMA: Don't enforce ACS check for device
> functions of Intel GPUs
> 
> On 25.09.25 12:51, Thomas Hellström wrote:
> >>> In that case I strongly suggest to add a private DMA-buf interface
> >>> for the DMA-
> >>> bufs exported by vfio-pci which returns which BAR and offset the
> >>> DMA-buf
> >>> represents.
> >
> > @Christian, Is what you're referring to here the "dma_buf private
> > interconnect" we've been discussing previously, now only between vfio-
> > pci and any interested importers instead of private to a known exporter
> > and importer?
> >
> > If so I have a POC I can post as an RFC on a way to negotiate such an
> > interconnect.
I'll start testing with the RFC patches Thomas posted and see how they can
be improved to make them suitable not only for this use-case but also for
the other (iommufd/kvm) use-cases as well.

> 
> I was just about to write something up as well, but feel free to go ahead if
> you already have something.
> 
> >> Does this private dmabuf interface already exist or does it need to
> >> be created
> >> from the ground up?
> 
> Every driver which supports both exporting and importing DMA-buf has
> code to detect when somebody tries to re-import a buffer previously
> exported from the same device.
> 
> Now some drivers like amdgpu and I think XE as well also detect if the buffer
> is from another device handled by the same driver which potentially have
> private interconnects (XGMI or similar).
> 
> See function amdgpu_dmabuf_is_xgmi_accessible() in amdgpu_dma_buf.c
> for an example.
> 
> >> If it already exists, could you please share an example/reference of
> >> how you
> >> have used it with amdgpu or other drivers?
> 
> Well what's new is that we need to do this between two drivers unreleated
> to each other.
Right, that is a key difference.

> 
> As far as I know previously that was all inside AMD drivers for example,
> while in this case vfio is a common vendor agnostic driver.
> 
> So we should probably make sure to get that right and vendor agnostic
> etc....
> 
> >> If it doesn't exist, I was wondering if it should be based on any
> >> particular best
> >> practices/ideas (or design patterns) that already exist in other
> >> drivers?
> >
> > @Vivek, another question: Also on the guest side we're exporting dma-
> > mapped adresses that are imported and somehow decoded by the guest
> > virtio-gpu driver? Is something similar needed there?
AFAICS, nothing else is needed because Qemu is the one that decodes or
resolves the dma-mapped addresses (that are imported by virtio-gpu) and
identifies the right memory region (and its owner, which could be a vfio-dev
or system memory). Details are found in the last patch of this Qemu series:
https://lore.kernel.org/qemu-devel/20250903054438.1179384-1-vivek.kasireddy@intel.com/

> >
> > Also how would the guest side VF driver know that what is assumed to be
> > a PF on the same device is actually a PF on the same device and not a
> > completely different device with another driver? (In which case I
> > assume it would like to export a system dma-buf)?
Good question. AFAICS, there is no definitive way for the Xe VF driver to
know who is the ultimate consumer of its buffer on the Host side. In other
words, the real question is how should it decide whether to create the
dmabuf from VRAM or migrate the backing object to system memory and
then create the dmabuf. Here are a few options I have tried so far:
1) If the importer (virtio-gpu) has allow_peer2peer set to true, and if Xe
is running in VF mode, then assume that PF of the same device is active
on the Host side and thus create a dmabuf from VRAM.

2) Rely on the user (or admin) that is launching Qemu to determine if the PF
on the Host and the VF are compatible (same device) and therefore configure
virtio-gpu and the VF device to be virtual P2P peers like this:
   qemu-system-x86_64 -m 4096m ....
  -device ioh3420,id=root_port1,bus=pcie.0
  -device x3130-upstream,id=upstream1,bus=root_port1
  -device xio3130-downstream,id=downstream1,bus=upstream1,chassis=9
  -device xio3130-downstream,id=downstream2,bus=upstream1,chassis=10
  -device vfio-pci,host=0000:03:00.1,bus=downstream1
  -device virtio-gpu,max_outputs=1,blob=true,xres=1920,yres=1080,bus=downstream2
  -display gtk,gl=on

I am sure there may be better ideas but I think the first option above is a lot
more straightforward. However, currently, virtio-gpu's allow_peer2peer is
always set to true but I'd like to set it to false and add a Qemu option to toggle 
it while launching the VM. This way the user gets to decide (based on what
GPU device is active on the Host) whether the Xe VF driver can create the
dmabuf from system memory or VRAM.

> 
> Another question is how is lifetime handled? E.g. does the guest know that
> a DMA-buf exists for it's BAR area?
Yes, the Guest VM knows that. The virtio-gpu driver (a dynamic importer)
which imports the scanout buffer from Xe VF driver calls dma_buf_pin().
So, the backing object stays pinned until Host/Qemu signals (via a fence)
that it is done accessing (or using) the Guest's buffer.

Also, note that since virtio-gpu registers a move_notify() callback, it can
let Qemu know of any location changes associated with the backing store
of the imported scanout buffer by sending attach_backing and
detach_backing cmds.

Thanks,
Vivek

> 
> Regards,
> Christian.
> 
> >
> > Thanks,
> > Thomas
> >
> >
> >
> >>
> >>>
> >>> Ideally using the same structure Qemu used to provide the offset to
> >>> the vfio-
> >>> pci driver, but not a must have.
> >>>
> >>> This way the driver for the GPU PF (XE) can leverage this
> >>> interface, validates
> >>> that the DMA-buf comes from a VF it feels responsible for and do
> >>> the math to
> >>> figure out in which parts of the VRAM needs to be accessed to
> >>> scanout the
> >>> picture.
> >> Sounds good. This is definitely a viable path forward and it looks
> >> like we are all
> >> in agreement with this idea.
> >>
> >> I guess we can start exploring how to implement the private dmabuf
> >> interface
> >> mechanism right away.
> >>
> >> Thanks,
> >> Vivek
> >>
> >>>
> >>> This way this private vfio-pci interface can also be used by
> >>> iommufd for
> >>> example.
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>>
> >>>> Thanks,
> >>>> Vivek
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Christian.
> >>>>>
> >>>>>>
> >>>>>>> What Simona agreed on is exactly what I proposed as well,
> >>>>>>> that you
> >>>>>>> get a private interface for exactly that use case.
> >>>>>>
> >>>>>> A "private" interface to exchange phys_addr_t between at
> >>>>>> least
> >>>>>> VFIO/KVM/iommufd - sure no complaint with that.
> >>>>>>
> >>>>>> Jason
> >>>>
> >>
> >