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=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 72B83C433E1 for ; Thu, 20 Aug 2020 05:16:16 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 CC4C920786 for ; Thu, 20 Aug 2020 05:16:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="SkzlkNUJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC4C920786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 5439C1668; Thu, 20 Aug 2020 07:15:24 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 5439C1668 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1597900574; bh=oM2b0m8qtPYoI+q1QGUr+uiwv1PyvIGFKoJQxzyxVlU=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=SkzlkNUJj4OtJp14gwtSzy7ojVruD2UU1OwxY9RGETUgYa00diXfQk6AE4iSGjbSv qEG4vGUXV/1YiSnPcQ3gUkHcUWDdF95C5A+orImaswCLedYuIvTNdSLkRR8pI+5fIR MDGBEq8J9ldaLJjMHzGS0kbSJu55hYYJ2HOiAs9c= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id C956CF801F9; Thu, 20 Aug 2020 07:15:23 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DA374F80228; Thu, 20 Aug 2020 07:15:21 +0200 (CEST) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0E2E8F80114 for ; Thu, 20 Aug 2020 07:15:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0E2E8F80114 Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. 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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 923E3C433E1 for ; Thu, 20 Aug 2020 05:15:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B9D220786 for ; Thu, 20 Aug 2020 05:15:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725828AbgHTFPT (ORCPT ); Thu, 20 Aug 2020 01:15:19 -0400 Received: from verein.lst.de ([213.95.11.211]:40549 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725798AbgHTFPT (ORCPT ); Thu, 20 Aug 2020 01:15:19 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Cc: Christoph Hellwig , Mauro Carvalho Chehab , Thomas Bogendoerfer , "James E.J. Bottomley" , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Ben Skeggs , Pawel Osciak , Marek Szyprowski , Matt Porter , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Tom Lendacky , alsa-devel@alsa-project.org, linux-samsung-soc , linux-ia64@vger.kernel.org, linux-scsi@vger.kernel.org, linux-parisc@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, Linux Kernel Mailing List , linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Media Mailing List Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Thu, 20 Aug 2020 05:15:12 +0000 Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-Id: <20200820051512.GA5141@lst.de> List-Id: References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomasz Figa Cc: Christoph Hellwig , Mauro Carvalho Chehab , Thomas Bogendoerfer , "James E.J. Bottomley" , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Ben Skeggs , Pawel Osciak , Marek Szyprowski , Matt Porter , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Tom Lendacky , alsa-devel@alsa-project.org, linux-samsung-soc , linux-ia64@vger.kernel.org, linux-scsi@vger.kernel.org, linux-parisc@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, Linux Kernel Mailing List , linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Media Mailing List On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. 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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 B5179C433DF for ; Thu, 20 Aug 2020 05:15:22 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 8B8FD2078B for ; Thu, 20 Aug 2020 05:15:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B8FD2078B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 2D6242151F; Thu, 20 Aug 2020 05:15:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQdrBe9opxdU; Thu, 20 Aug 2020 05:15:21 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id ED28B2050C; Thu, 20 Aug 2020 05:15:20 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA8EFC07FF; Thu, 20 Aug 2020 05:15:20 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 497D5C0051 for ; Thu, 20 Aug 2020 05:15:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 29C00863E0 for ; Thu, 20 Aug 2020 05:15:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59FvW93bgyIO for ; Thu, 20 Aug 2020 05:15:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 64E5A86396 for ; Thu, 20 Aug 2020 05:15:18 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-5.2 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,USER_AGENT_SANE_1 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 66198C433E3 for ; Thu, 20 Aug 2020 05:15:29 +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 391A020786 for ; Thu, 20 Aug 2020 05:15:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Cuv5C9Pe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 391A020786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvme-bounces+linux-nvme=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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Nn4XiOxNrC00lm6ICNPXClq3LVMobrPp68Elnw++WYQ=; b=Cuv5C9PeHEpizqkrmIOlNzwx5 J1oYvOGW/X/4Qp3FV9MwjkR5avrQUG+4zQS3ZFddu5stve8PXdwrRk13hlKzVbeW27SRPnrhNZ476 8ImK/BvJADuxUoGtiK42Ws88ImFU1f+NoK6ADY0H18JWBZ6r70a5RN2tMY//mapnGqDBsuKVZIJxR mzDFSLwFsjulBJnibwx4cGn3Pe5TcmhvBiM+xiLS+Zwr4z5+fR4s14vKd4luWEUstFwr0bnXXHJuZ GfDZzO/kVUO9goI/ObCKthCfFzHcWRw5hogqgfxEfM5G4DCSCRx21gqFiQBkqdI+KxpRYXAs7/iie epUY47l9A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8cv4-0006I9-R9; Thu, 20 Aug 2020 05:15:22 +0000 Received: from verein.lst.de ([213.95.11.211]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8cuz-0006GO-9u; Thu, 20 Aug 2020 05:15:17 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_011517_473217_33F14F45 X-CRM114-Status: GOOD ( 20.46 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Date: Thu, 20 Aug 2020 07:15:12 +0200 Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-media-owner@vger.kernel.org To: Tomasz Figa Cc: Christoph Hellwig , Mauro Carvalho Chehab , Thomas Bogendoerfer , "James E.J. Bottomley" , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Ben Skeggs , Pawel Osciak , Marek Szyprowski , Matt Porter , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Tom Lendacky , alsa-devel@alsa-project.org, linux-samsung-soc , linux-ia64@vger.kernel.org, linux-scsi@vger List-Id: nouveau.vger.kernel.org On Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. 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=-5.3 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,USER_AGENT_SANE_1 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 64729C433E1 for ; Thu, 20 Aug 2020 05:16:53 +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 2F38020786 for ; Thu, 20 Aug 2020 05:16:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lvhXZb/o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F38020786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NZGweGZfaVZSbTiP8lVTjaWDNhmdG5H8ofbUS/uTCWs=; b=lvhXZb/ouin489ibaYLy+xZjL XnSwAY1QqZlt0Eat+1PzEh46P4pvPft5RnfhpXuy+I9m0MHdGUBmfS7JVOmrzoACXkWQNTtsZiXOq s0hJngKIW80Fh4lBBcx7ffIov6Z3GJ5zOQDx6EQWp0t/4ZdPwmQnTz2Zqk+6VQCwm5koCTogz6/1Z aUiq6DZZiHLCM9johuQOwkDvEXTSA5kx+m54xb2ip/hF6PQtui1QT1lcbgKTdA+z6S7CIJabp0gcf a+ir1vjcLhQH44pif8N4wfr95VclCSzbWtJXwMxTziK/fOfU6bmPGHSH1tbL2tfg5k+4sNiwBXjbA S99kPSJsA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8cv1-0006HD-Pg; Thu, 20 Aug 2020 05:15:19 +0000 Received: from verein.lst.de ([213.95.11.211]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8cuz-0006GO-9u; Thu, 20 Aug 2020 05:15:17 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id A894C68BEB; Thu, 20 Aug 2020 07:15:12 +0200 (CEST) Date: Thu, 20 Aug 2020 07:15:12 +0200 From: Christoph Hellwig To: Tomasz Figa Subject: Re: [PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc, free}_pages Message-ID: <20200820051512.GA5141@lst.de> References: <20200819065555.1802761-1-hch@lst.de> <20200819065555.1802761-20-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_011517_473217_33F14F45 X-CRM114-Status: GOOD ( 20.46 ) 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: alsa-devel@alsa-project.org, linux-ia64@vger.kernel.org, Linux Doc Mailing List , nouveau@lists.freedesktop.org, linux-nvme@lists.infradead.org, linux-mips@vger.kernel.org, "James E.J. Bottomley" , linux-mm@kvack.org, Christoph Hellwig , Marek Szyprowski , linux-samsung-soc , Joonyoung Shim , linux-scsi@vger.kernel.org, Kyungmin Park , Ben Skeggs , Matt Porter , Linux Media Mailing List , Tom Lendacky , Pawel Osciak , Mauro Carvalho Chehab , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, Seung-Woo Kim , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " 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 Wed, Aug 19, 2020 at 05:03:52PM +0200, Tomasz Figa wrote: > > > > -Warning: These pieces of the DMA API should not be used in the > > -majority of cases, since they cater for unlikely corner cases that > > -don't belong in usual drivers. > > +These APIs allow to allocate pages that can be used like normal pages > > +in the kernel direct mapping, but are guaranteed to be DMA addressable. > > Could we elaborate a bit more on what "like normal pages in kernel > direct mapping" mean from the driver perspective? It mostly means you can call virt_to_page and then do anything you'd do with a page struct. Unlike dma_alloc_attrs that just return an opaque virtual address that the caller is not allowed to poke into. > There is one aspect that the existing dma_alloc_attrs() handles, but > this new function doesn't: IOMMU support. The function will always > allocate a physically-contiguous block memory, which is a costly > operation and not even guaranteed to succeed, even if enough free > memory is available. > > Modern SoCs employ IOMMUs to avoid the need to allocate > physically-contiguous memory and those happen to be also the devices > that could benefit from non-coherent allocations a lot. One of the > tasks of the DMA API was making it possible to allocate suitable > memory for a given device, without having the driver know about the > SoC integration details, such as the presence of an IOMMU. This is completely out of scope for this API exactly because it guarantees a page in the direct mapping. But see my previous mail in reply to Robin on how you can implement the funtionality you want right now without any help from the dma-mapping subsystem. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel