From: Jason Gunthorpe <jgg@mellanox.com>
To: Niranjan 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: Mon, 25 Nov 2019 13:24:18 +0000 [thread overview]
Message-ID: <20191125132414.GQ7481@mellanox.com> (raw)
In-Reply-To: <20191124211247.GF14488@nvishwa1-DESK.sc.intel.com>
On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote:
> > > > Using a temporary range is the pattern from nouveau, is it really
> > > > necessary in this driver?
> > >
> > > Yah, not required. In my local build I tried with proper default_flags
> > > and set pfn_flags_mask to 0 and it is working fine.
> >
> > Sorry, I ment calling hmm_range_register during fault processing.
> >
> > If your driver works around user space objects that cover a VA then
> > the range should be created when the object is created.
> >
>
> Oh ok. No, there is no user space object here.
> Binding the user space object to device page table is handled in
> patch 03 of this series (no HMM there).
> This is for binding a system allocated (malloc) memory. User calls
> the bind ioctl with the VA range.
>
> > > > > + /*
> > > > > + * 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?
> > >
> > > The sgl is used to plug into the page table update function in i915.
> > >
> > > For the device memory in discrete card, we don't need dma map which
> > > is the case here.
> >
> > How did we get to device memory on a card? Isn't range->pfns a CPU PFN
> > at this point?
> >
> > I'm confused.
>
> Device memory plugin is done through devm_memremap_pages() in patch 07 of
> this series. In that patch, we convert the CPU PFN to device PFN before
> building the sgl (this is similar to the nouveau driver).
But earlier just called hmm_range_fault(), it can return all kinds of
pages. If these are only allowed to be device pages here then that
must be checked (under lock)
And putting the cpu PFN of a ZONE_DEVICE device page into
sg_dma_address still looks very wrong to me
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: Niranjan 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>,
"sudeep.dutt@intel.com" <sudeep.dutt@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>,
"jon.bloomfield@intel.com" <jon.bloomfield@intel.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: Mon, 25 Nov 2019 13:24:18 +0000 [thread overview]
Message-ID: <20191125132414.GQ7481@mellanox.com> (raw)
Message-ID: <20191125132418.yS7FBGdCVqmjC6D_Pn9Kz0c-JgsHiHSANQOdvwHk0rk@z> (raw)
In-Reply-To: <20191124211247.GF14488@nvishwa1-DESK.sc.intel.com>
On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote:
> > > > Using a temporary range is the pattern from nouveau, is it really
> > > > necessary in this driver?
> > >
> > > Yah, not required. In my local build I tried with proper default_flags
> > > and set pfn_flags_mask to 0 and it is working fine.
> >
> > Sorry, I ment calling hmm_range_register during fault processing.
> >
> > If your driver works around user space objects that cover a VA then
> > the range should be created when the object is created.
> >
>
> Oh ok. No, there is no user space object here.
> Binding the user space object to device page table is handled in
> patch 03 of this series (no HMM there).
> This is for binding a system allocated (malloc) memory. User calls
> the bind ioctl with the VA range.
>
> > > > > + /*
> > > > > + * 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?
> > >
> > > The sgl is used to plug into the page table update function in i915.
> > >
> > > For the device memory in discrete card, we don't need dma map which
> > > is the case here.
> >
> > How did we get to device memory on a card? Isn't range->pfns a CPU PFN
> > at this point?
> >
> > I'm confused.
>
> Device memory plugin is done through devm_memremap_pages() in patch 07 of
> this series. In that patch, we convert the CPU PFN to device PFN before
> building the sgl (this is similar to the nouveau driver).
But earlier just called hmm_range_fault(), it can return all kinds of
pages. If these are only allowed to be device pages here then that
must be checked (under lock)
And putting the cpu PFN of a ZONE_DEVICE device page into
sg_dma_address still looks very wrong to me
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-25 13:24 UTC|newest]
Thread overview: 70+ 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 ` [RFC 01/13] drm/i915/svm: Add SVM documentation Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 02/13] drm/i915/svm: Define SVM UAPI Niranjana Vishwanathapura
2019-11-22 20:57 ` Niranjana Vishwanathapura
2019-11-26 13:44 ` Joonas Lahtinen
2019-11-26 13:44 ` Joonas Lahtinen
2019-11-28 2:04 ` Niranjan Vishwanathapura
2019-11-28 2:04 ` Niranjan Vishwanathapura
2019-11-22 20:57 ` [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support Niranjana Vishwanathapura
2019-11-22 20:57 ` 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-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 ` 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 ` Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 06/13] drm/i915/svm: Page table mirroring support Niranjana Vishwanathapura
2019-11-22 20:57 ` Niranjana Vishwanathapura
2019-11-22 23:33 ` Jason Gunthorpe
2019-11-22 23:33 ` Jason Gunthorpe
2019-11-23 4:44 ` Niranjan Vishwanathapura
2019-11-23 4:44 ` Niranjan Vishwanathapura
2019-11-23 23:53 ` Jason Gunthorpe
2019-11-23 23:53 ` Jason Gunthorpe
2019-11-24 21:12 ` Niranjan Vishwanathapura
2019-11-24 21:12 ` Niranjan Vishwanathapura
2019-11-25 13:24 ` Jason Gunthorpe [this message]
2019-11-25 13:24 ` Jason Gunthorpe
2019-11-25 16:32 ` Niranjan Vishwanathapura
2019-11-26 18:45 ` Jason Gunthorpe
2019-11-26 18:45 ` Jason Gunthorpe
2019-12-03 19:07 ` Niranjan Vishwanathapura
2019-11-25 16:34 ` Jerome Glisse
2019-11-25 16:34 ` Jerome Glisse
2019-11-25 16:33 ` Jerome Glisse
2019-11-25 21:29 ` Niranjan Vishwanathapura
2019-11-26 18:32 ` Jason Gunthorpe
2019-11-26 18:32 ` 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 ` 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 ` [RFC 09/13] drm/i915/svm: Page copy support during migration Niranjana Vishwanathapura
2019-11-22 20:57 ` 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 ` 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 ` [RFC 12/13] drm/i915/svm: Add support to en/disable SVM Niranjana Vishwanathapura
2019-11-22 20:57 ` Niranjana Vishwanathapura
2019-11-22 20:57 ` [RFC 13/13] drm/i915/svm: Add page table dump support Niranjana Vishwanathapura
2019-11-26 14:03 ` [RFC 00/13] drm/i915/svm: Add SVM support Joonas Lahtinen
2019-11-26 14:03 ` Joonas Lahtinen
2019-12-02 19:37 ` Niranjan Vishwanathapura
2019-12-02 19:37 ` 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:01 ` Niranjan Vishwanathapura
2019-11-22 20:14 ` Jason Gunthorpe
2019-11-22 20:11 ` Niranjan Vishwanathapura
2019-11-22 20:14 ` Jason Gunthorpe
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=20191125132414.GQ7481@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