From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "DRI Development" <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>,
"Dan Williams" <dan.j.williams@intel.com>,
"Linux MM" <linux-mm@kvack.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Pawel Osciak" <pawel@osciak.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Tomasz Figa" <tfiga@chromium.org>,
"Inki Dae" <inki.dae@samsung.com>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>,
"Oded Gabbay" <oded.gabbay@gmail.com>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Tue, 6 Oct 2020 00:43:31 +0200 [thread overview]
Message-ID: <CAKMK7uHRxK3yNrvX=+n-XpSv7PDCz8w+mwof3pkUUJq3TpmiuQ@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uH97Yb2JFviG_ynGC1hbQ69h9hcyFVFd2PFYHCDzfBN6g@mail.gmail.com>
On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote:
> >
> > > > kvm is some similar hack added for P2P DMA, see commit
> > > > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers..
> > >
> > > Yeah my thinking is that kvm (and I think also vfio, also seems to
> > > have mmu notifier nearby) are ok because of the mmu notiifer. Assuming
> > > that one works correctly.
> >
> > vfio doesn't have a notifier, Alex was looking to add a vfio private
> > scheme in the vma->private_data:
> >
> > https://lore.kernel.org/kvm/159017449210.18853.15037950701494323009.stgit@gimli.home/
> >
> > Guess it never happened.
>
> I was mislead by the mmu notifier in drivers/vfio/vfio.c. But looking
> closer, that's only used by some drivers, I guess to make sure their
> device pagetables are kept in sync with reality. And not to make sure
> the vfio pfn view is kept in sync with reality.
>
> This could get real nasty I think.
>
> > > > So, the answer really is that s390 and media need fixing, and this API
> > > > should go away (or become kvm specific)
> > >
> > > I'm still not clear how you want fo fix this, since your vma->dma_buf
> > > idea is kinda a decade long plan and so just not going to happen:
> >
> > Well, it doesn't mean we have to change every part of dma_buf to
> > participate in this. Just the bits media cares about. Or maybe it is
> > some higher level varient on top of dma_buf.
> >
> > Or don't use dma_buf for this, add a new object that just provides
> > refcounts and P2P DMA connection for IO pfn ranges..
>
> So good news is, I dug some layers deeper in v4l, and there's only 2
> users which do actually handle pfn and don't immediately convert to a
> pages array:
> - videbuf-dma-contig.c. Luckily videobuf 1 is deprecated since
> forever, so I think we might get away with either just breaking this,
> or at least tainting kernels and hiding it behind a nasty Kconfig.
> This only uses follow_pfn, which we need to keep anyway for vfio in
> the unsafe variant :-/
> - videbuf2-vmalloc.c Digging through history this was added to support
> import of v4l buffers from drivers that needed contig memory. And way
> back before CMA, that meant carveout memory not backed by struct page
> *. That should now all have struct pages and be managed by CMA (since
> videbuf2-dma-contig.c just uses dma_alloc_coherent underneath), so I
> think we can just switch to pin_user_pages(FOLL_LONGTERM here too).
>
> iow I think I can outright delete the frame vector stuff.
Ok this doesn't work, because dma_mmap always uses a remap_pfn_range,
which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and
not a carveout, we can't get the pages. Plus trying to move the cma
pages out of cma for FOLL_LONGTERM would be kinda bad when they've
been allocated as a contig block by dma_alloc_coherent :-)
So this idea of switching over to pup only is going to break zerocopy.
I guess I'll need something else for this then.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2020-10-05 22:43 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 17:53 [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames() Daniel Vetter
2020-10-02 17:53 ` [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Daniel Vetter
2020-10-02 18:06 ` Jason Gunthorpe
2020-10-02 18:16 ` Daniel Vetter
2020-10-02 23:31 ` Jason Gunthorpe
2020-10-03 8:34 ` Oded Gabbay
2020-10-03 9:40 ` Daniel Vetter
2020-10-04 12:50 ` Jason Gunthorpe
2020-10-04 16:09 ` Daniel Vetter
2020-10-05 17:28 ` Jason Gunthorpe
2020-10-05 18:16 ` Daniel Vetter
2020-10-05 18:37 ` Jason Gunthorpe
2020-10-05 18:54 ` Daniel Vetter
2020-10-05 22:43 ` Daniel Vetter [this message]
2020-10-05 23:41 ` Jason Gunthorpe
2020-10-06 6:23 ` Daniel Vetter
2020-10-06 12:26 ` Jason Gunthorpe
2020-10-06 13:08 ` Daniel Vetter
2020-10-07 10:47 ` Marek Szyprowski
2020-10-07 12:01 ` Daniel Vetter
2020-10-07 12:33 ` Marek Szyprowski
2020-10-07 12:44 ` Jason Gunthorpe
2020-10-07 12:47 ` Tomasz Figa
2020-10-07 12:58 ` Daniel Vetter
2020-10-07 13:06 ` Jason Gunthorpe
2020-10-07 13:34 ` Tomasz Figa
2020-10-07 13:42 ` Jason Gunthorpe
2020-10-07 14:08 ` Daniel Vetter
2020-10-07 14:11 ` Tomasz Figa
2020-10-07 14:22 ` Daniel Vetter
2020-10-07 15:05 ` Tomasz Figa
2020-10-07 14:58 ` Jason Gunthorpe
2020-10-07 13:06 ` Tomasz Figa
2020-10-07 13:14 ` Jason Gunthorpe
2020-10-05 15:03 ` Jan Kara
2020-10-02 22:39 ` John Hubbard
2020-10-03 9:45 ` Daniel Vetter
2020-10-03 22:52 ` John Hubbard
2020-10-03 23:24 ` Jason Gunthorpe
2020-10-04 11:20 ` Daniel Vetter
2020-10-05 17:35 ` Jason Gunthorpe
2020-10-02 18:22 ` [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames() Tomasz Figa
2020-10-02 19:21 ` Oded Gabbay
2020-10-05 17:38 [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Jason Gunthorpe
2020-10-05 17:47 ` Jason Gunthorpe
2020-10-06 3:36 ` Andrew Morton
2020-10-06 11:57 ` Jason Gunthorpe
2020-10-05 17:53 ` Jan Kara
2020-10-05 17:57 ` Jason Gunthorpe
2020-10-05 18:16 ` Daniel Vetter
2020-10-06 11:56 ` Daniel Vetter
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='CAKMK7uHRxK3yNrvX=+n-XpSv7PDCz8w+mwof3pkUUJq3TpmiuQ@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=jy0922.shim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=oded.gabbay@gmail.com \
--cc=pawel@osciak.com \
--cc=sw0312.kim@samsung.com \
--cc=tfiga@chromium.org \
/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).