From: Matthew Brost <matthew.brost@intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>
Subject: Re: [PATCH 2/2] drm/xe: RFC Deny unbinds if uapi ufence pending
Date: Thu, 15 Feb 2024 06:33:33 +0000 [thread overview]
Message-ID: <Zc2wPWDoZJFUfCIU@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <871q9f3zdt.fsf@mkuoppal-desk>
On Wed, Feb 14, 2024 at 04:15:58PM +0200, Mika Kuoppala wrote:
> Mika Kuoppala <mika.kuoppala@linux.intel.com> writes:
>
> > If user fence was provided for MAP in vm_bind_ioctl
> > and it has still not been signalled, deny UNMAP of said
> > vma with EBUSY as long as unsignalled fence exists.
> >
> > This guarantees that MAP vs UNMAP sequences won't
> > escape under the radar if we ever want to track the
> > client's state wrt to completed and accessible MAPs.
> > By means of intercepting the ufence release signalling.
> >
> > Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1159
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_vm.c | 22 ++++++++++++++++++++++
> > drivers/gpu/drm/xe/xe_vm_types.h | 7 +++++++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> > index 836a6e849cda8..c26297568e697 100644
> > --- a/drivers/gpu/drm/xe/xe_vm.c
> > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > @@ -897,6 +897,11 @@ static void xe_vma_destroy_late(struct xe_vma *vma)
> > struct xe_device *xe = vm->xe;
> > bool read_only = xe_vma_read_only(vma);
> >
> > + if (vma->ufence) {
> > + xe_sync_ufence_put(vma->ufence);
> > + vma->ufence = NULL;
> > + }
> > +
> > if (xe_vma_is_userptr(vma)) {
> > struct xe_userptr *userptr = &to_userptr_vma(vma)->userptr;
> >
> > @@ -1608,6 +1613,16 @@ xe_vm_unbind_vma(struct xe_vma *vma, struct xe_exec_queue *q,
> >
> > trace_xe_vma_unbind(vma);
> >
> > + if (vma->ufence) {
> > + struct xe_user_fence * const f = vma->ufence;
> > +
> > + if (!xe_sync_ufence_get_status(f))
> > + return ERR_PTR(-EBUSY);
> > +
> > + vma->ufence = NULL;
> > + xe_sync_ufence_put(f);
> > + }
> > +
> > if (number_tiles > 1) {
> > fences = kmalloc_array(number_tiles, sizeof(*fences),
> > GFP_KERNEL);
> > @@ -1751,6 +1766,13 @@ static int __xe_vm_bind(struct xe_vm *vm, struct xe_vma *vma,
> >
> > xe_vm_assert_held(vm);
> >
> > + if (num_syncs == 1 && xe_sync_is_ufence(&syncs[0])) {
Maybe a helper here? Also I think it is possible for num_syncs > 1 and
have a ufence too.
> > + if (XE_WARN_ON(vma->ufence))
>
> This will get triggered with xe_exec_threads: threads-cm-userptr.
>
> Should we just silently swap into a newer provided ufence
> and only complain if the existing fence in here is still non signalled?
>
CI caught a failure too [1].
I think the failure in threads-cm-userptr must be a userptr invalidation
triggering a rebind? In this case the ufence will not be signaled but
vma->ufence == xe_sync_is_ufence(&syncs[0]).
For [1], I think it is possible that ufence could not be signaled too.
With that I believe is ok just to swap without an error.
Matt
[1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-129900v1/bat-pvc-2/igt@xe_exec_fault_mode@twice-basic-prefetch.html
> -Mika
>
> > + xe_sync_ufence_put(vma->ufence);
> > +
> > + vma->ufence = xe_sync_ufence_get(&syncs[0]);
> > + }
> > +
> > if (immediate) {
> > fence = xe_vm_bind_vma(vma, q, syncs, num_syncs, first_op,
> > last_op);
> > diff --git a/drivers/gpu/drm/xe/xe_vm_types.h b/drivers/gpu/drm/xe/xe_vm_types.h
> > index 5ac9c5bebabc3..4a06420b941ea 100644
> > --- a/drivers/gpu/drm/xe/xe_vm_types.h
> > +++ b/drivers/gpu/drm/xe/xe_vm_types.h
> > @@ -19,6 +19,7 @@
> >
> > struct xe_bo;
> > struct xe_sync_entry;
> > +struct xe_user_fence;
> > struct xe_vm;
> >
> > #define XE_VMA_READ_ONLY DRM_GPUVA_USERBITS
> > @@ -102,6 +103,12 @@ struct xe_vma {
> > * @pat_index: The pat index to use when encoding the PTEs for this vma.
> > */
> > u16 pat_index;
> > +
> > + /**
> > + * @ufence: The user fence that was provided with MAP.
> > + * Needs to be signalled before UNMAP can be processed.
> > + */
> > + struct xe_user_fence *ufence;
> > };
> >
> > /**
> > --
> > 2.34.1
next prev parent reply other threads:[~2024-02-15 6:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 14:12 [PATCH 1/2] drm/xe: Expose user fence from xe_sync_entry Mika Kuoppala
2024-02-14 14:12 ` [PATCH 2/2] drm/xe: RFC Deny unbinds if uapi ufence pending Mika Kuoppala
2024-02-14 14:15 ` Mika Kuoppala
2024-02-15 6:33 ` Matthew Brost [this message]
2024-02-14 14:20 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe: Expose user fence from xe_sync_entry Patchwork
2024-02-14 14:21 ` ✗ CI.checkpatch: warning " Patchwork
2024-02-14 14:22 ` ✓ CI.KUnit: success " Patchwork
2024-02-14 14:32 ` ✓ CI.Build: " Patchwork
2024-02-14 14:33 ` ✓ CI.Hooks: " Patchwork
2024-02-14 14:34 ` ✓ CI.checksparse: " Patchwork
2024-02-14 15:03 ` ✗ CI.BAT: failure " Patchwork
2024-02-15 6:18 ` [PATCH 1/2] " Matthew Brost
2024-02-15 11:17 ` Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zc2wPWDoZJFUfCIU@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=mika.kuoppala@linux.intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.