From: Jason Gunthorpe <jgg@mellanox.com>
To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: "kenneth.w.graunke@intel.com" <kenneth.w.graunke@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"sanjay.k.kumar@intel.com" <sanjay.k.kumar@intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"jason.ekstrand@intel.com" <jason.ekstrand@intel.com>,
"dave.hansen@intel.com" <dave.hansen@intel.com>,
"jglisse@redhat.com" <jglisse@redhat.com>,
"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"ira.weiny@intel.com" <ira.weiny@intel.com>
Subject: Re: [Intel-gfx] [RFC v2 05/12] drm/i915/svm: Page table mirroring support
Date: Tue, 17 Dec 2019 20:31:07 +0000 [thread overview]
Message-ID: <20191217203103.GG16762@mellanox.com> (raw)
In-Reply-To: <20191213215614.24558-6-niranjana.vishwanathapura@intel.com>
On Fri, Dec 13, 2019 at 01:56:07PM -0800, Niranjana Vishwanathapura wrote:
> +static struct i915_svm *vm_get_svm(struct i915_address_space *vm)
> +{
> + struct i915_svm *svm = vm->svm;
> +
> + mutex_lock(&vm->svm_mutex);
> + if (svm && !kref_get_unless_zero(&svm->ref))
> + svm = NULL;
Quite strange to see a get_unless_zero under a lock..
> +static void release_svm(struct kref *ref)
> +{
> + struct i915_svm *svm = container_of(ref, typeof(*svm), ref);
> + struct i915_address_space *vm = svm->vm;
> +
> + mmu_notifier_unregister(&svm->notifier, svm->notifier.mm);
This would be a lot better to use mmu_notifier_put to manage the
reference and deallocation.
> +static u32 i915_svm_build_sg(struct i915_address_space *vm,
> + struct hmm_range *range,
> + struct sg_table *st)
> +{
> + struct scatterlist *sg;
> + u32 sg_page_sizes = 0;
> + u64 i, npages;
> +
> + sg = NULL;
> + st->nents = 0;
> + npages = (range->end - range->start) / PAGE_SIZE;
> +
> + /*
> + * No need to dma map the host pages and later unmap it, as
> + * GPU is not allowed to access it with SVM.
> + * XXX: Need to dma map host pages for integrated graphics while
> + * extending SVM support there.
> + */
> + for (i = 0; i < npages; i++) {
> + u64 addr = range->pfns[i] & ~((1UL << range->pfn_shift) - 1);
> +
> + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> + sg->length += PAGE_SIZE;
> + sg_dma_len(sg) += PAGE_SIZE;
> + continue;
> + }
> +
> + if (sg)
> + sg_page_sizes |= sg->length;
> +
> + sg = sg ? __sg_next(sg) : st->sgl;
> + sg_dma_address(sg) = addr;
> + sg_dma_len(sg) = PAGE_SIZE;
This still can't be like this - assigning pfn to 'dma_address' is
fundamentally wrong.
Whatever explanation you had, this needs to be fixed up first before we get
to this patch.
> +static int i915_range_fault(struct svm_notifier *sn,
> + struct drm_i915_gem_vm_bind *args,
> + struct sg_table *st, u64 *pfns)
> +{
> + unsigned long timeout =
> + jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> + /* Have HMM fault pages within the fault window to the GPU. */
> + struct hmm_range range = {
> + .notifier = &sn->notifier,
> + .start = sn->notifier.interval_tree.start,
> + .end = sn->notifier.interval_tree.last + 1,
> + .pfns = pfns,
> + .pfn_shift = PAGE_SHIFT,
> + .flags = i915_range_flags,
> + .values = i915_range_values,
> + .default_flags = (range.flags[HMM_PFN_VALID] |
> + ((args->flags & I915_GEM_VM_BIND_READONLY) ?
> + 0 : range.flags[HMM_PFN_WRITE])),
> + .pfn_flags_mask = 0,
> +
> + };
> + struct i915_svm *svm = sn->svm;
> + struct mm_struct *mm = sn->notifier.mm;
> + struct i915_address_space *vm = svm->vm;
> + u32 sg_page_sizes;
> + u64 flags;
> + long ret;
> +
> + while (true) {
> + if (time_after(jiffies, timeout))
> + return -EBUSY;
> +
> + range.notifier_seq = mmu_interval_read_begin(range.notifier);
> + down_read(&mm->mmap_sem);
> + ret = hmm_range_fault(&range, 0);
> + up_read(&mm->mmap_sem);
> + if (ret <= 0) {
> + if (ret == 0 || ret == -EBUSY)
> + continue;
> + return ret;
> + }
> +
> + sg_page_sizes = i915_svm_build_sg(vm, &range, st);
> + mutex_lock(&svm->mutex);
> + if (mmu_interval_read_retry(range.notifier,
> + range.notifier_seq)) {
> + mutex_unlock(&svm->mutex);
> + continue;
> + }
> + break;
> + }
> +
> + flags = (args->flags & I915_GEM_VM_BIND_READONLY) ?
> + I915_GTT_SVM_READONLY : 0;
> + ret = svm_bind_addr_commit(vm, args->start, args->length,
> + flags, st, sg_page_sizes);
> + mutex_unlock(&svm->mutex);
This looks better..
> +int i915_gem_vm_bind_svm_buffer(struct i915_address_space *vm,
> + struct drm_i915_gem_vm_bind *args)
> +{
> + struct svm_notifier sn;
> + struct i915_svm *svm;
> + struct mm_struct *mm;
> + struct sg_table st;
> + u64 npages, *pfns;
> + int ret = 0;
> +
> + svm = vm_get_svm(vm);
> + if (!svm)
> + return -EINVAL;
> +
> + mm = svm->notifier.mm;
> + if (mm != current->mm) {
> + ret = -EPERM;
> + goto bind_done;
> + }
Bit strange, we have APIs now to make it fairly easy to deal with
multiple processe, (ie the get/put scheme) why have this restriction?
> +
> + args->length += (args->start & ~PAGE_MASK);
> + args->start &= PAGE_MASK;
> + DRM_DEBUG_DRIVER("%sing start 0x%llx length 0x%llx vm_id 0x%x\n",
> + (args->flags & I915_GEM_VM_BIND_UNBIND) ?
> + "Unbind" : "Bind", args->start, args->length,
> + args->vm_id);
> + if (args->flags & I915_GEM_VM_BIND_UNBIND) {
> + i915_gem_vm_unbind_svm_buffer(vm, args->start, args->length);
> + goto bind_done;
> + }
> +
> + npages = args->length / PAGE_SIZE;
> + if (unlikely(sg_alloc_table(&st, npages, GFP_KERNEL))) {
> + ret = -ENOMEM;
> + goto bind_done;
> + }
> +
> + pfns = kvmalloc_array(npages, sizeof(uint64_t), GFP_KERNEL);
> + if (unlikely(!pfns)) {
> + ret = -ENOMEM;
> + goto range_done;
> + }
> +
> + ret = svm_bind_addr_prepare(vm, args->start, args->length);
> + if (unlikely(ret))
> + goto prepare_done;
> +
> + sn.svm = svm;
> + ret = mmu_interval_notifier_insert(&sn.notifier, mm,
> + args->start, args->length,
> + &i915_svm_mni_ops);
> + if (!ret) {
> + ret = i915_range_fault(&sn, args, &st, pfns);
> + mmu_interval_notifier_remove(&sn.notifier);
> + }
success oriented flow...
> +static int
> +i915_svm_invalidate_range_start(struct mmu_notifier *mn,
> + const struct mmu_notifier_range *update)
> +{
> + struct i915_svm *svm = container_of(mn, struct i915_svm, notifier);
> + unsigned long length = update->end - update->start;
> +
> + DRM_DEBUG_DRIVER("start 0x%lx length 0x%lx\n", update->start, length);
> + if (!mmu_notifier_range_blockable(update))
> + return -EAGAIN;
> +
> + i915_gem_vm_unbind_svm_buffer(svm->vm, update->start, length);
> + return 0;
> +}
I still think you should strive for a better design than putting a
notifier across the entire address space..
> +
> +#if defined(CONFIG_DRM_I915_SVM)
> +struct i915_svm {
> + /* i915 address space */
> + struct i915_address_space *vm;
> +
> + struct mmu_notifier notifier;
> + struct mutex mutex; /* protects svm operations */
> + /*
> + * XXX: Probably just make use of mmu_notifier's reference
> + * counting (get/put) instead of our own.
> + */
Yes
Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-12-17 20:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 21:56 [Intel-gfx] [RFC v2 00/12] drm/i915/svm: Add SVM support Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 01/12] drm/i915/svm: Add SVM documentation Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support Niranjana Vishwanathapura
2019-12-13 22:58 ` Jason Ekstrand
2019-12-13 23:13 ` Niranjan Vishwanathapura
2019-12-14 0:36 ` Jason Ekstrand
2019-12-14 10:31 ` Chris Wilson
2019-12-16 4:13 ` Niranjan Vishwanathapura
2019-12-17 18:01 ` Jason Ekstrand
2019-12-18 23:25 ` Niranjana Vishwanathapura
2019-12-14 10:56 ` Chris Wilson
2019-12-16 4:15 ` Niranjan Vishwanathapura
2019-12-18 22:51 ` Niranjana Vishwanathapura
2019-12-17 20:18 ` Jason Gunthorpe
2019-12-18 23:34 ` Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 03/12] drm/i915/svm: Implicitly migrate BOs upon CPU access Niranjana Vishwanathapura
2019-12-14 10:58 ` Chris Wilson
2019-12-16 4:17 ` Niranjan Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 04/12] drm/i915/svm: Page table update support for SVM Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 05/12] drm/i915/svm: Page table mirroring support Niranjana Vishwanathapura
2019-12-17 20:31 ` Jason Gunthorpe [this message]
2019-12-18 22:41 ` Niranjana Vishwanathapura
2019-12-20 13:45 ` Jason Gunthorpe
2019-12-22 19:54 ` Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 06/12] drm/i915/svm: Device memory support Niranjana Vishwanathapura
2019-12-17 20:35 ` Jason Gunthorpe
2019-12-18 22:15 ` Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 07/12] drm/i915/svm: Implicitly migrate pages upon CPU fault Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 08/12] drm/i915/svm: Page copy support during migration Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 09/12] drm/i915/svm: Add functions to blitter copy SVM buffers Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 10/12] drm/i915/svm: Use blitter copy for migration Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 11/12] drm/i915/svm: Add support to en/disable SVM Niranjana Vishwanathapura
2019-12-13 21:56 ` [Intel-gfx] [RFC v2 12/12] drm/i915/svm: Add page table dump support Niranjana Vishwanathapura
2019-12-14 1:32 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/svm: Add SVM support (rev2) Patchwork
2020-01-24 8:42 ` [Intel-gfx] [RFC v2 00/12] drm/i915/svm: Add SVM support Niranjana Vishwanathapura
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=20191217203103.GG16762@mellanox.com \
--to=jgg@mellanox.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dave.hansen@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ira.weiny@intel.com \
--cc=jason.ekstrand@intel.com \
--cc=jglisse@redhat.com \
--cc=kenneth.w.graunke@intel.com \
--cc=niranjana.vishwanathapura@intel.com \
--cc=sanjay.k.kumar@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox