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: "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>,
	"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: [RFC 06/13] drm/i915/svm: Page table mirroring support
Date: Fri, 22 Nov 2019 23:33:12 +0000	[thread overview]
Message-ID: <20191122233308.GA7481@mellanox.com> (raw)
In-Reply-To: <20191122205734.15925-7-niranjana.vishwanathapura@intel.com>

On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:

> +static inline bool
> +i915_range_done(struct hmm_range *range)
> +{
> +	bool ret = hmm_range_valid(range);
> +
> +	hmm_range_unregister(range);
> +	return ret;
> +}

This needs to be updated to follow the new API, but this pattern is
generally wrong, failure if hmm_range_valid should retry the
range_fault and so forth. See the hmm.rst.

> +static int
> +i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
> +{
> +	long ret;
> +
> +	range->default_flags = 0;
> +	range->pfn_flags_mask = -1UL;
> +
> +	ret = hmm_range_register(range, &svm->mirror);
> +	if (ret) {
> +		up_read(&svm->mm->mmap_sem);
> +		return (int)ret;
> +	}


Using a temporary range is the pattern from nouveau, is it really
necessary in this driver?

> +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 needd to dma map the host pages and later unmap it, as
> +	 * GPU is not allowed to access it with SVM. Hence, no need
> +	 * of any intermediate data strucutre to hold the mappings.
> +	 */
> +	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;
> +		sg->length = PAGE_SIZE;
> +		st->nents++;

It is odd to build the range into a sgl.

IMHO it is not a good idea to use the sg_dma_address like this, that
should only be filled in by a dma map. Where does it end up being
used?

> +	range.pfn_shift = PAGE_SHIFT;
> +	range.start = args->start;
> +	range.flags = i915_range_flags;
> +	range.values = i915_range_values;
> +	range.end = range.start + args->length;
> +	for (i = 0; i < npages; ++i) {
> +		range.pfns[i] = range.flags[HMM_PFN_VALID];
> +		if (!(args->flags & I915_BIND_READONLY))
> +			range.pfns[i] |= range.flags[HMM_PFN_WRITE];
> +	}
> +
> +	down_read(&svm->mm->mmap_sem);
> +	vma = find_vma(svm->mm, range.start);

Why is find_vma needed?

> +	if (unlikely(!vma || vma->vm_end < range.end)) {
> +		ret = -EFAULT;
> +		goto vma_done;
> +	}
> +again:
> +	ret = i915_range_fault(svm, &range);
> +	if (unlikely(ret))
> +		goto vma_done;
> +
> +	sg_page_sizes = i915_svm_build_sg(vm, &range, &st);
>

Keep in mind what can be done with the range values is limited until
the lock is obtained. Reading the pfns and flags is OK though.

> +int i915_svm_bind_mm(struct i915_address_space *vm)
> +{
> +	struct i915_svm *svm;
> +	struct mm_struct *mm;
> +	int ret = 0;
> +
> +	mm = get_task_mm(current);

I don't think the get_task_mm(current) is needed, the mmget is already
done for current->mm ?

Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@mellanox.com>
To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: "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>,
	"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 06/13] drm/i915/svm: Page table mirroring support
Date: Fri, 22 Nov 2019 23:33:12 +0000	[thread overview]
Message-ID: <20191122233308.GA7481@mellanox.com> (raw)
Message-ID: <20191122233312.t_GhjdaaPhPwtmZ_1WXLKpQxCSdTVM_pbEu40h0rpig@z> (raw)
In-Reply-To: <20191122205734.15925-7-niranjana.vishwanathapura@intel.com>

On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:

> +static inline bool
> +i915_range_done(struct hmm_range *range)
> +{
> +	bool ret = hmm_range_valid(range);
> +
> +	hmm_range_unregister(range);
> +	return ret;
> +}

This needs to be updated to follow the new API, but this pattern is
generally wrong, failure if hmm_range_valid should retry the
range_fault and so forth. See the hmm.rst.

> +static int
> +i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
> +{
> +	long ret;
> +
> +	range->default_flags = 0;
> +	range->pfn_flags_mask = -1UL;
> +
> +	ret = hmm_range_register(range, &svm->mirror);
> +	if (ret) {
> +		up_read(&svm->mm->mmap_sem);
> +		return (int)ret;
> +	}


Using a temporary range is the pattern from nouveau, is it really
necessary in this driver?

> +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 needd to dma map the host pages and later unmap it, as
> +	 * GPU is not allowed to access it with SVM. Hence, no need
> +	 * of any intermediate data strucutre to hold the mappings.
> +	 */
> +	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;
> +		sg->length = PAGE_SIZE;
> +		st->nents++;

It is odd to build the range into a sgl.

IMHO it is not a good idea to use the sg_dma_address like this, that
should only be filled in by a dma map. Where does it end up being
used?

> +	range.pfn_shift = PAGE_SHIFT;
> +	range.start = args->start;
> +	range.flags = i915_range_flags;
> +	range.values = i915_range_values;
> +	range.end = range.start + args->length;
> +	for (i = 0; i < npages; ++i) {
> +		range.pfns[i] = range.flags[HMM_PFN_VALID];
> +		if (!(args->flags & I915_BIND_READONLY))
> +			range.pfns[i] |= range.flags[HMM_PFN_WRITE];
> +	}
> +
> +	down_read(&svm->mm->mmap_sem);
> +	vma = find_vma(svm->mm, range.start);

Why is find_vma needed?

> +	if (unlikely(!vma || vma->vm_end < range.end)) {
> +		ret = -EFAULT;
> +		goto vma_done;
> +	}
> +again:
> +	ret = i915_range_fault(svm, &range);
> +	if (unlikely(ret))
> +		goto vma_done;
> +
> +	sg_page_sizes = i915_svm_build_sg(vm, &range, &st);
>

Keep in mind what can be done with the range values is limited until
the lock is obtained. Reading the pfns and flags is OK though.

> +int i915_svm_bind_mm(struct i915_address_space *vm)
> +{
> +	struct i915_svm *svm;
> +	struct mm_struct *mm;
> +	int ret = 0;
> +
> +	mm = get_task_mm(current);

I don't think the get_task_mm(current) is needed, the mmget is already
done for current->mm ?

Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-11-22 23:33 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22 20:57 [RFC 00/13] drm/i915/svm: Add SVM support Niranjana Vishwanathapura
2019-11-22 20:57 ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 01/13] drm/i915/svm: Add SVM documentation Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 02/13] drm/i915/svm: Define SVM UAPI Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-26 13:44   ` Joonas Lahtinen
2019-11-26 13:44     ` [Intel-gfx] " Joonas Lahtinen
2019-11-28  2:04     ` Niranjan Vishwanathapura
2019-11-28  2:04       ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-22 20:57 ` [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-25  9:59   ` Chris Wilson
2019-11-25  9:59     ` [Intel-gfx] " Chris Wilson
2019-11-25 16:40     ` Niranjan Vishwanathapura
2019-11-25 16:40       ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-26 13:59       ` Joonas Lahtinen
2019-11-26 13:59         ` Joonas Lahtinen
2019-11-27 19:23         ` Niranjan Vishwanathapura
2019-11-27 19:23           ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-28 12:12           ` Joonas Lahtinen
2019-11-28 12:12             ` [Intel-gfx] " Joonas Lahtinen
2019-12-02 19:59             ` Niranjan Vishwanathapura
2019-12-02 19:59               ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-22 20:57 ` [RFC 04/13] drm/i915/svm: Implicitly migrate BOs upon CPU access Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 05/13] drm/i915/svm: Page table update support for SVM Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 06/13] drm/i915/svm: Page table mirroring support Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 23:33   ` Jason Gunthorpe [this message]
2019-11-22 23:33     ` Jason Gunthorpe
2019-11-23  4:44     ` Niranjan Vishwanathapura
2019-11-23  4:44       ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-23 23:53       ` Jason Gunthorpe
2019-11-23 23:53         ` [Intel-gfx] " Jason Gunthorpe
2019-11-24 21:12         ` Niranjan Vishwanathapura
2019-11-24 21:12           ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-25 13:24           ` Jason Gunthorpe
2019-11-25 13:24             ` [Intel-gfx] " Jason Gunthorpe
2019-11-25 16:32             ` Niranjan Vishwanathapura
2019-11-25 16:32               ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-26 18:45               ` Jason Gunthorpe
2019-11-26 18:45                 ` [Intel-gfx] " Jason Gunthorpe
2019-12-03 19:07                 ` Niranjan Vishwanathapura
2019-11-25 16:34             ` Jerome Glisse
2019-11-25 16:34               ` [Intel-gfx] " Jerome Glisse
2019-11-25 16:33     ` Jerome Glisse
2019-11-25 16:33       ` [Intel-gfx] " Jerome Glisse
2019-11-25 21:29       ` Niranjan Vishwanathapura
2019-11-25 21:29         ` [Intel-gfx] " Niranjan Vishwanathapura
2019-11-26 18:32       ` Jason Gunthorpe
2019-11-26 18:32         ` [Intel-gfx] " Jason Gunthorpe
2019-12-03 19:19         ` Niranjan Vishwanathapura
2019-12-04 21:51           ` Jerome Glisse
2019-12-08 18:23             ` Jason Gunthorpe
2019-11-22 20:57 ` [RFC 07/13] drm/i915/svm: Device memory support Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 08/13] drm/i915/svm: Implicitly migrate pages upon CPU fault Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 09/13] drm/i915/svm: Page copy support during migration Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 10/13] drm/i915/svm: Add functions to blitter copy SVM buffers Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 11/13] drm/i915/svm: Use blitter copy for migration Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 12/13] drm/i915/svm: Add support to en/disable SVM Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 13/13] drm/i915/svm: Add page table dump support Niranjana Vishwanathapura
2019-11-22 20:57   ` [Intel-gfx] " Niranjana Vishwanathapura
2019-11-22 21:32 ` ✗ Fi.CI.BUILD: failure for drm/i915/svm: Add SVM support Patchwork
2019-11-22 21:32   ` [Intel-gfx] " Patchwork
2019-11-26 14:03 ` [RFC 00/13] " Joonas Lahtinen
2019-11-26 14:03   ` [Intel-gfx] " Joonas Lahtinen
2019-12-02 19:37   ` Niranjan Vishwanathapura
2019-12-02 19:37     ` [Intel-gfx] " Niranjan Vishwanathapura
     [not found] <20191122195452.14346-1-niranjana.vishwanathapura@intel.com>
     [not found] ` <20191122195452.14346-7-niranjana.vishwanathapura@intel.com>
2019-11-22 20:01   ` [RFC 06/13] drm/i915/svm: Page table mirroring support Niranjan Vishwanathapura
2019-11-22 20:14     ` Jason Gunthorpe
2019-11-22 20:11       ` Niranjan 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=20191122233308.GA7481@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=jglisse@redhat.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