Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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