From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B273C4363A for ; Mon, 5 Oct 2020 22:43:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8340A2078A for ; Mon, 5 Oct 2020 22:43:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="KVtqpLQo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726754AbgJEWnn (ORCPT ); Mon, 5 Oct 2020 18:43:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725846AbgJEWnm (ORCPT ); Mon, 5 Oct 2020 18:43:42 -0400 Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D78FBC0613CE for ; Mon, 5 Oct 2020 15:43:42 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id c13so10485468oiy.6 for ; Mon, 05 Oct 2020 15:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=KVtqpLQoesSPzYMWv+7UD1tFkDy5yyjPi/++9DOuPkCf87SQu/2kTZ3idGVZKfPwCd pibU61WH7YP7EEL4itAZdaANj+S6XlMqVnXbtEak6sUMU90UHCO+zSFAMUExqUb1YOcT JXHEL9SJtjDQ6Ed3u1L2W1biaZ1QQkU7lcDcg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=H684LPG9oR2h3gvZN/w/DcduKfrNF7V0xfzROL8PeGy7t16gxLdv2L/8SmdpXrAmIa TsAINx+B+6PuQhDf0Iv867AcFbQQ9KwK6/5xVloDtbzFxxmXooyoDeUPrJFz2S7hikat 4lR+FXawH1Sd3ruh5VQcohZz5+/hRolj17NtC03+C40tv5YqMX53lDFraPHBLK3lK4Q5 NtJmk4fuFJ+BCjk/ELgbpOZdZZYYDBzkM81Hj2JSzEQFnLrlqzUEJhQX/vlp2qHKFfFE ssYWom2oNSSzaXRtb7Kt2/TbEE2PTuGnfog1W024jCJY5WYPjUts3PbXprhagBsg1BCh AJag== X-Gm-Message-State: AOAM533KD5SPrpwGrvnV5O/5I0hSxhxqsF1QK8vAt5U3mHJBDiSwGlMy i6nSXyWtfs8WLCtVUUTZS/umvqcEehsyms58mlFKAg== X-Google-Smtp-Source: ABdhPJyfoPYCOpkuTCOIXoCW2mDiwodpJmuvAJrKdJ2P/BzfZGqk4dj/BBdhzJ7DBqSgjSfRXX8X8v1vcNJVJjv0Yog= X-Received: by 2002:aca:52c4:: with SMTP id g187mr467717oib.101.1601937822236; Mon, 05 Oct 2020 15:43:42 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Tue, 6 Oct 2020 00:43:31 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams , Linux MM , Linux ARM , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Inki Dae , Joonyoung Shim , Seung-Woo Kim , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Oded Gabbay Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter wrote: > > On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 306C6C4363A for ; Mon, 5 Oct 2020 22:45:13 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA9C0206C3 for ; Mon, 5 Oct 2020 22:45:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="obH3Hc61"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="KVtqpLQo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA9C0206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cNx8rvWGjvklbTBV29z6w0XXIYrmP5fBVu+bTIC9jfA=; b=obH3Hc61AIe7YaGX/1515BYpZ 0NJ1kOrU2zlTxffwuPpoGM/nWsPtMPejvPrKhkU88q1/NZ/mCdFeerOahrhzaxlxymm0/DDycfhjS yz/Oty8rcv9Cpt9fB462RSGaGsKOhg8neKRKI8CKnJ4z7dHJNVHi+7CzN/duj3zlld9yO6Mgro7TL +Fk4kjO7b/Kg7JdQCAt1qjzrEE78e28Gcp0v82g9CT9rMZ1cqPE60Vh/fDq4R8h5nSdD+XEcwNW0F CycG+9UE8qZGcjz9s9+KmhMaOO4YL0ih2CaxSAAdSjS7LmQZZulAlhmIsUsm7QWlnTnT0B9NT/ITx H2Qb5+bJQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPZCu-0001Tq-D2; Mon, 05 Oct 2020 22:43:48 +0000 Received: from mail-oi1-x241.google.com ([2607:f8b0:4864:20::241]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPZCq-0001Ss-Mg for linux-arm-kernel@lists.infradead.org; Mon, 05 Oct 2020 22:43:45 +0000 Received: by mail-oi1-x241.google.com with SMTP id 26so10485833ois.5 for ; Mon, 05 Oct 2020 15:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=KVtqpLQoesSPzYMWv+7UD1tFkDy5yyjPi/++9DOuPkCf87SQu/2kTZ3idGVZKfPwCd pibU61WH7YP7EEL4itAZdaANj+S6XlMqVnXbtEak6sUMU90UHCO+zSFAMUExqUb1YOcT JXHEL9SJtjDQ6Ed3u1L2W1biaZ1QQkU7lcDcg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=umi1EGgsNxu0UUxpMLi0GQck6YkNZGH8CfsVo2AdBgAitBEP2w+3hylwsK28LfVAKO PwmKJ3DCXZ098dP9Y9tS6o539oJOU9UkvsX8jDCzzUaeLpw7G+pFoM0Cv+RVD8Lpk9zO tR6hHIj/hI6us0eupAVUxxk39pa9wVqX3Xw9j+3Xtwu6b3qkIw8TbgZz2zpJJY7JnNN8 T9jUzkUyAojyeyrRrxpMQjmLf42LtsisAXTK/bP8NRChAkaxZvwD/HptwT4U5VpsPeMs FL5MnMbtAnrmGy3zefkI1qn2dzi57IAE7J5LVrf2i9zCjoLl3HmEnmtDuuDlgnwV3XkQ Lmgg== X-Gm-Message-State: AOAM5327GcEC0cQEV3R/vrBAKqAc0yZ/IwDNkg2HFFYF2GqFgBqH79Td zEmkXziirjRP2c8M5Im8jpOBlWvXn4Nv67+HK03sxw== X-Google-Smtp-Source: ABdhPJyfoPYCOpkuTCOIXoCW2mDiwodpJmuvAJrKdJ2P/BzfZGqk4dj/BBdhzJ7DBqSgjSfRXX8X8v1vcNJVJjv0Yog= X-Received: by 2002:aca:52c4:: with SMTP id g187mr467717oib.101.1601937822236; Mon, 05 Oct 2020 15:43:42 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Tue, 6 Oct 2020 00:43:31 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201005_184344_797664_216D58A5 X-CRM114-Status: GOOD ( 30.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Oded Gabbay , Inki Dae , linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter wrote: > > On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A81BC4363D for ; Mon, 5 Oct 2020 22:43:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 79AAD206C3 for ; Mon, 5 Oct 2020 22:43:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="KVtqpLQo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79AAD206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7591B6E185; Mon, 5 Oct 2020 22:43:44 +0000 (UTC) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id EA89E6E185 for ; Mon, 5 Oct 2020 22:43:42 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id l85so10477715oih.10 for ; Mon, 05 Oct 2020 15:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=KVtqpLQoesSPzYMWv+7UD1tFkDy5yyjPi/++9DOuPkCf87SQu/2kTZ3idGVZKfPwCd pibU61WH7YP7EEL4itAZdaANj+S6XlMqVnXbtEak6sUMU90UHCO+zSFAMUExqUb1YOcT JXHEL9SJtjDQ6Ed3u1L2W1biaZ1QQkU7lcDcg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=n9XtDAIFIm5thO84FXU7vBNcaakD7xLpWwzPnFS0z6IaCq8t6jiEgODoKc830FLPiT xuZAewVF2DTG7PyP0iB2/+XXNNCXZURMZ68gEroIlMVb05frp77ZsP/+MBHVs7TOFc1t vMicEz4xfI5qImpnYKQnyYUeistlt/tlyDpLXEjAGQ6sJEmJ8ST0yaiOYwA4T3iVK3CO Ync4eGNmOxD78j3tvsdxRnNVUWKb2sBvaHpwsvZJXRq88aLJSTiW3Y10U+G50raYQHTz 1csVjm1rJjRplpKX1AXyuy1Ya0sicccPU3kcUsXm2EG3ExnQlfy6B3d3fNDKuby7883p 8J2g== X-Gm-Message-State: AOAM5303ZcVXzzqufjpJA91Dm06DtIbqdPuJ2ovh6T6VWhbzqmLYAMs9 sLULEV12WTEUyjDwgB3VB7wjsT/ayLt4ZWX6au9BlQ== X-Google-Smtp-Source: ABdhPJyfoPYCOpkuTCOIXoCW2mDiwodpJmuvAJrKdJ2P/BzfZGqk4dj/BBdhzJ7DBqSgjSfRXX8X8v1vcNJVJjv0Yog= X-Received: by 2002:aca:52c4:: with SMTP id g187mr467717oib.101.1601937822236; Mon, 05 Oct 2020 15:43:42 -0700 (PDT) MIME-Version: 1.0 References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Tue, 6 Oct 2020 00:43:31 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter wrote: > > On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel