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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id AACFDC38145 for ; Wed, 7 Sep 2022 14:47:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42AA310E794; Wed, 7 Sep 2022 14:47:32 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id B80E410E78B for ; Wed, 7 Sep 2022 14:47:27 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E318C61948 for ; Wed, 7 Sep 2022 14:47:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE520C43142 for ; Wed, 7 Sep 2022 14:47:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662562045; bh=f2o1y7KshjpkY9lv8qUib+ioQ3G6ppr6671x+zJpSF4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aLkBQKdLoh3iU88fbas6ii+45gySIpTjxbicxQs534bhWawTDK6a9h/Y8dROIVnYt 5HqJs+58zWLLHVpz5+ed2hF8NhGRkKPP555vl4nHw7q6ixSz+tPA9ilmxHx0MsAeYA xWIGsSs3YxTov4kyaEdIuTVVIp3A86248pvsxeb8mu4RQEkz87sLGuopFfcqzb3OSo 9nSz3RS6bEKslJ8Or1KY5iNA0oRzTd3cyDOpW2ErfhwGE8LqhxGD/ir/2bSpFqoWo7 9gRsrF/aiEtWxktJXYK2t9ntg0TqF/FFM6jTa3ma2wtLbw0K9iJvLqKzLvZVA3QA8R ph0+BOJIq6vwQ== Received: by mail-il1-f175.google.com with SMTP id m16so4671585ilg.3 for ; Wed, 07 Sep 2022 07:47:25 -0700 (PDT) X-Gm-Message-State: ACgBeo2Koh9fx/iv0d2WPScCWKhSaPaIoDC+za8nANkjIeycflQbuKhm UjftejxqSXp4wP+7VTFQ9pyEYpnNZkVbl4C0iyQ= X-Google-Smtp-Source: AA6agR4o6lWldMLAmLaGf8/79sK+50kODsD1YRVgj4S5LMXqrOSaAz5a6xplMki6HW5XZ9A7aIrChvyctdcUSFL6CzA= X-Received: by 2002:a05:6e02:1548:b0:2ea:836d:ac6c with SMTP id j8-20020a056e02154800b002ea836dac6cmr2206779ilu.6.1662562044874; Wed, 07 Sep 2022 07:47:24 -0700 (PDT) MIME-Version: 1.0 References: <0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com> <4-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com> In-Reply-To: From: Oded Gabbay Date: Wed, 7 Sep 2022 17:46:58 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf To: Christoph Hellwig Content-Type: text/plain; charset="UTF-8" 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: Leon Romanovsky , KVM list , linux-rdma , Daniel Vetter , Cornelia Huck , Maling list - DRI developers , Sumit Semwal , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Alex Williamson , Jason Gunthorpe , Dan Williams , Maor Gottlieb , =?UTF-8?Q?Christian_K=C3=B6nig?= , Linux Media Mailing List Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Sep 7, 2022 at 5:30 PM Christoph Hellwig wrote: > > On Wed, Sep 07, 2022 at 09:33:11AM -0300, Jason Gunthorpe wrote: > > Yes, you said that, and I said that when the AMD driver first merged > > it - but it went in anyhow and now people are using it in a bunch of > > places. > > drm folks made up their own weird rules, if they internally stick > to it they have to listen to it given that they ignore review comments, > but it violates the scatterlist API and has not business anywhere > else in the kernel. And yes, there probably is a reason or two why > the drm code is unusually error prone. > > > > Why would small BARs be problematic for the pages? The pages are more > > > a problem for gigantic BARs do the memory overhead. > > > > How do I get a struct page * for a 4k BAR in vfio? > > I guess we have different definitions of small then :) > > But unless my understanding of the code is out out of data, > memremap_pages just requires the (virtual) start address to be 2MB > aligned, not the size. Adding Dan for comments. > > That being said, what is the point of mapping say a 4k BAR for p2p? > You're not going to save a measurable amount of CPU overhead if that > is the only place you transfer to. I don't know what Jason had in mind, but I can see a use for that for writing to doorbells of a device. Today, usually what happens is that peer A reads/writes to peer B's memory through the large bar and then signals the host the operation was completed. Then the host s/w writes to the doorbell of the peer B to let him know he can continue with the execution as the data is now ready (or can be recycled). I can imagine peer A writing directly to the doorbell of peer B, and usually for that we would like to expose a very small area, probably a single 4K page. Oded