User fences are intended to be used on long running VMs, enforce this restriction. This addresses possible concerns of using user fences in dma-fence and having the dma-fence signal before the user fence.
Fixes: d1df9bfbf68c ("drm/xe: Only allow 1 ufence per exec / bind IOCTL") Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost matthew.brost@intel.com --- drivers/gpu/drm/xe/xe_exec.c | 3 ++- drivers/gpu/drm/xe/xe_vm.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 97eeb973e897..a145813ad229 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -168,7 +168,8 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) { + if (XE_IOCTL_DBG(xe, num_ufence > 1) || + XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) { err = -EINVAL; goto err_syncs; } diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 26b409e1b0f0..85da3a8a83b6 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3226,7 +3226,8 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) { + if (XE_IOCTL_DBG(xe, num_ufence > 1) || + XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) { err = -EINVAL; goto free_syncs; }
Hi,
On Mon, 2024-06-03 at 10:53 -0700, Matthew Brost wrote:
User fences are intended to be used on long running VMs, enforce this restriction. This addresses possible concerns of using user fences in dma-fence and having the dma-fence signal before the user fence.
As mentioned in a separate thread, We should not introduce an uAPI change with the above motivation. We need to discuss potential use- cases for !LR vms and if there are found to be none, we could consider restricting in this way.
/Thomas
Fixes: d1df9bfbf68c ("drm/xe: Only allow 1 ufence per exec / bind IOCTL") Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost matthew.brost@intel.com
drivers/gpu/drm/xe/xe_exec.c | 3 ++- drivers/gpu/drm/xe/xe_vm.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 97eeb973e897..a145813ad229 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -168,7 +168,8 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) {
- if (XE_IOCTL_DBG(xe, num_ufence > 1) ||
- XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) {
err = -EINVAL; goto err_syncs; } diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 26b409e1b0f0..85da3a8a83b6 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3226,7 +3226,8 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) {
- if (XE_IOCTL_DBG(xe, num_ufence > 1) ||
- XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) {
err = -EINVAL; goto free_syncs; }
On Mon, Jun 03, 2024 at 10:42:19PM +0200, Thomas Hellström wrote:
Hi,
On Mon, 2024-06-03 at 10:53 -0700, Matthew Brost wrote:
User fences are intended to be used on long running VMs, enforce this restriction. This addresses possible concerns of using user fences in dma-fence and having the dma-fence signal before the user fence.
As mentioned in a separate thread, We should not introduce an uAPI change with the above motivation. We need to discuss potential use-
Sure. Agree this is really an orthogonal change to the other thread. Just noticed we didn't have restriction when typing in that thread.
cases for !LR vms and if there are found to be none, we could consider restricting in this way.
IMO we should strongly consider this as conceptually gives a clear seperation of synchronization between non-LR and LR VMs.
Matt
/Thomas
Fixes: d1df9bfbf68c ("drm/xe: Only allow 1 ufence per exec / bind IOCTL") Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost matthew.brost@intel.com
drivers/gpu/drm/xe/xe_exec.c | 3 ++- drivers/gpu/drm/xe/xe_vm.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 97eeb973e897..a145813ad229 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -168,7 +168,8 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) {
- if (XE_IOCTL_DBG(xe, num_ufence > 1) ||
- XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) {
err = -EINVAL; goto err_syncs; } diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 26b409e1b0f0..85da3a8a83b6 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3226,7 +3226,8 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void *data, struct drm_file *file) num_ufence++; }
- if (XE_IOCTL_DBG(xe, num_ufence > 1)) {
- if (XE_IOCTL_DBG(xe, num_ufence > 1) ||
- XE_IOCTL_DBG(xe, num_ufence && !xe_vm_in_lr_mode(vm))) {
err = -EINVAL; goto free_syncs; }
linux-stable-mirror@lists.linaro.org