From: Christoph Hellwig <hch@lst.de>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>,
Christoph Hellwig <hch@lst.de>,
Jerome Glisse <jglisse@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Christian Koenig <christian.koenig@amd.com>,
Felix Kuehling <Felix.Kuehling@amd.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <jroedel@suse.de>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
Date: Thu, 31 Jan 2019 09:13:55 +0100 [thread overview]
Message-ID: <20190131081355.GC26495@lst.de> (raw)
In-Reply-To: <07baf401-4d63-b830-57e1-5836a5149a0c@deltatee.com>
On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > *shrug* so what if the special GUP called a VMA op instead of
> > traversing the VMA PTEs today? Why does it really matter? It could
> > easily change to a struct page flow tomorrow..
>
> Well it's so that it's composable. We want the SGL->DMA side to work for
> APIs from kernel space and not have to run a completely different flow
> for kernel drivers than from userspace memory.
Yes, I think that is the important point.
All the other struct page discussion is not about anyone of us wanting
struct page - heck it is a pain to deal with, but then again it is
there for a reason.
In the typical GUP flows we have three uses of a struct page:
(1) to carry a physical address. This is mostly through
struct scatterlist and struct bio_vec. We could just store
a magic PFN-like value that encodes the physical address
and allow looking up a page if it exists, and we had at least
two attempts at it. In some way I think that would actually
make the interfaces cleaner, but Linus has NACKed it in the
past, so we'll have to convince him first that this is the
way forward
(2) to keep a reference to the memory so that it doesn't go away
under us due to swapping, process exit, unmapping, etc.
No idea how we want to solve this, but I guess you have
some smart ideas?
(3) to make the PTEs dirty after writing to them. Again no sure
what our preferred interface here would be
If we solve all of the above problems I'd be more than happy to
go with a non-struct page based interface for BAR P2P. But we'll
have to solve these issues in a generic way first.
next prev parent reply other threads:[~2019-01-31 8:13 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 17:47 [RFC PATCH 0/5] Device peer to peer (p2p) through vma jglisse
2019-01-29 17:47 ` [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability jglisse
2019-01-29 18:24 ` Logan Gunthorpe
2019-01-29 19:44 ` Greg Kroah-Hartman
2019-01-29 19:53 ` Jerome Glisse
2019-01-29 20:44 ` Logan Gunthorpe
2019-01-29 21:00 ` Jerome Glisse
2019-01-29 19:56 ` Alex Deucher
2019-01-29 20:00 ` Jerome Glisse
2019-01-29 20:24 ` Logan Gunthorpe
2019-01-29 21:28 ` Alex Deucher
2019-01-30 10:25 ` Christian König
2019-01-29 17:47 ` [RFC PATCH 2/5] drivers/base: " jglisse
2019-01-29 18:26 ` Logan Gunthorpe
2019-01-29 19:54 ` Jerome Glisse
2019-01-29 19:46 ` Greg Kroah-Hartman
2019-01-29 19:56 ` Jerome Glisse
2019-01-29 17:47 ` [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma jglisse
2019-01-29 18:36 ` Logan Gunthorpe
2019-01-29 19:11 ` Jerome Glisse
2019-01-29 19:24 ` Logan Gunthorpe
2019-01-29 19:44 ` Jerome Glisse
2019-01-29 20:43 ` Logan Gunthorpe
2019-01-30 7:52 ` Christoph Hellwig
2019-01-29 19:32 ` Jason Gunthorpe
2019-01-29 19:50 ` Jerome Glisse
2019-01-29 20:24 ` Jason Gunthorpe
2019-01-29 20:44 ` Jerome Glisse
2019-01-29 23:02 ` Jason Gunthorpe
2019-01-30 0:08 ` Jerome Glisse
2019-01-30 4:30 ` Jason Gunthorpe
2019-01-30 15:43 ` Jerome Glisse
2019-01-29 20:39 ` Logan Gunthorpe
2019-01-29 20:57 ` Jerome Glisse
2019-01-29 21:30 ` Logan Gunthorpe
2019-01-29 21:50 ` Jerome Glisse
2019-01-29 22:58 ` Logan Gunthorpe
2019-01-29 23:47 ` Jerome Glisse
2019-01-30 1:17 ` Logan Gunthorpe
2019-01-30 2:48 ` Jerome Glisse
2019-01-30 4:18 ` Jason Gunthorpe
2019-01-30 8:00 ` Christoph Hellwig
2019-01-30 15:49 ` Jerome Glisse
2019-01-30 19:06 ` Jason Gunthorpe
[not found] ` <20190130190651.GC17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:45 ` Logan Gunthorpe
[not found] ` <840256f8-0714-5d7d-e5f5-c96aec5c2c05-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 19:59 ` Jason Gunthorpe
[not found] ` <20190130195900.GG17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 21:01 ` Logan Gunthorpe
[not found] ` <35bad6d5-c06b-f2a3-08e6-2ed0197c8691-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 21:50 ` Jason Gunthorpe
[not found] ` <20190130215019.GL17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 22:52 ` Logan Gunthorpe
2019-01-30 23:30 ` Jason Gunthorpe
2019-01-31 8:13 ` Christoph Hellwig [this message]
2019-01-31 15:37 ` Jerome Glisse
2019-01-31 19:02 ` Jason Gunthorpe
2019-01-31 19:19 ` Logan Gunthorpe
2019-01-31 19:54 ` Jason Gunthorpe
2019-01-31 19:35 ` Jerome Glisse
2019-01-31 19:44 ` Logan Gunthorpe
2019-01-31 19:58 ` Jason Gunthorpe
2019-01-30 17:17 ` Logan Gunthorpe
[not found] ` <bdf03cd5-f5b1-4b78-a40e-b24024ca8c9f-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 18:56 ` Jason Gunthorpe
[not found] ` <20190130185652.GB17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:22 ` Jerome Glisse
2019-01-30 19:38 ` Jason Gunthorpe
[not found] ` <20190130193759.GE17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 20:00 ` Logan Gunthorpe
2019-01-30 20:11 ` Jason Gunthorpe
2019-01-30 20:43 ` Jerome Glisse
[not found] ` <20190130204332.GF5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 20:50 ` Jason Gunthorpe
2019-01-30 21:45 ` Jerome Glisse
[not found] ` <20190130214525.GG5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 21:56 ` Jason Gunthorpe
2019-01-30 22:30 ` Jerome Glisse
[not found] ` <20190130223027.GH5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 22:33 ` Jason Gunthorpe
2019-01-30 22:47 ` Jerome Glisse
[not found] ` <20190130224705.GI5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 22:51 ` Jason Gunthorpe
2019-01-30 22:58 ` Jerome Glisse
[not found] ` <20190130192234.GD5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 19:52 ` Logan Gunthorpe
2019-01-30 20:35 ` Jerome Glisse
2019-01-29 20:58 ` Jason Gunthorpe
2019-01-30 8:02 ` Christoph Hellwig
2019-01-30 10:33 ` Koenig, Christian
2019-01-30 15:55 ` Jerome Glisse
2019-01-30 17:26 ` Christoph Hellwig
2019-01-30 17:32 ` Logan Gunthorpe
2019-01-30 17:39 ` Jason Gunthorpe
2019-01-30 18:05 ` Jerome Glisse
2019-01-30 17:44 ` Jason Gunthorpe
2019-01-30 18:13 ` Logan Gunthorpe
2019-01-30 18:50 ` Jerome Glisse
2019-01-31 8:02 ` Christoph Hellwig
2019-01-31 15:03 ` Jerome Glisse
2019-01-30 19:19 ` Jason Gunthorpe
[not found] ` <20190130191946.GD17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:48 ` Logan Gunthorpe
2019-01-30 20:44 ` Jason Gunthorpe
2019-01-31 8:05 ` Christoph Hellwig
2019-01-31 15:11 ` Jerome Glisse
2019-01-29 17:47 ` [RFC PATCH 4/5] mm/hmm: add support for peer to peer to HMM device memory jglisse
2019-01-29 17:47 ` [RFC PATCH 5/5] mm/hmm: add support for peer to peer to special device vma jglisse
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=20190131081355.GC26495@lst.de \
--to=hch@lst.de \
--cc=Felix.Kuehling@amd.com \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.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;
as well as URLs for NNTP newsgroup(s).