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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40A82C433FE for ; Tue, 15 Feb 2022 03:08:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233750AbiBODIa (ORCPT ); Mon, 14 Feb 2022 22:08:30 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:33556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229545AbiBODI3 (ORCPT ); Mon, 14 Feb 2022 22:08:29 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5148BD7610; Mon, 14 Feb 2022 19:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644894500; x=1676430500; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=geRpObVSkW/4BdCaIv62nRssJKtA31qUc5woj+F+Kyw=; b=lhmsE3wMFDeT0NAb1/ZzKUE5sEO98n6Up8eYGzfv1BPXDy4yVZzwD8zh Wtka4nv036ANpwIDcZetmqKT76YFc6DurXTUmhhL0U+525F7VRNaWNh2e 8udKdgKLK6VoJTg075kgFiFzxQq8iE+fpXBzPKuWAI157mx90eGLBlOBT cb5id9VCQoz1qPm5iWFVIp/uVfoHmty40Mg6UC0zia8WeDhsuKWmqwhzx WJgnQWKtLn2Ize6ku+4iyrucExPsqdyMUniwnkDuxvHzXmH5kT8MJv+vy oGM2lFL2J/OGlMAmRSIylidTMpfHvLkW95+GALN4Ebs0zxYhELKD/R65R w==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="274811837" X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="274811837" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 19:08:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="680812468" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by fmsmga001.fm.intel.com with ESMTP; 14 Feb 2022 19:08:13 -0800 Message-ID: Date: Tue, 15 Feb 2022 11:06:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: baolu.lu@linux.intel.com, Joerg Roedel , Alex Williamson , Bjorn Helgaas , Christoph Hellwig , Kevin Tian , Ashok Raj , Will Deacon , Robin Murphy , Dan Williams , rafael@kernel.org, Diana Craciun , Cornelia Huck , Eric Auger , Liu Yi L , Jacob jun Pan , Chaitanya Kulkarni , Stuart Yoder , Laurentiu Tudor , Thierry Reding , David Airlie , Daniel Vetter , Jonathan Hunter , Li Yang , Dmitry Osipenko , iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 07/14] PCI: Add driver dma ownership management Content-Language: en-US To: Jason Gunthorpe , Greg Kroah-Hartman References: <20220104015644.2294354-1-baolu.lu@linux.intel.com> <20220104015644.2294354-8-baolu.lu@linux.intel.com> <20220214123842.GT4160@nvidia.com> <20220214131117.GW4160@nvidia.com> <20220214134356.GB929467@nvidia.com> From: Lu Baolu In-Reply-To: <20220214134356.GB929467@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/14/22 9:43 PM, Jason Gunthorpe wrote: > On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote: > >>> A driver that sets this flag can still decide to enable the dma API on >>> its own. eg tegra drivers do this. >> >> So you are just forcing the driver to manage this all on their own, so >> how about, "driver_managed_dma", or even shorter "managed_dma"? > > Yeah, I like "driver_managed_dma" alot, it captures the entire idea This makes a lot of sense. For most drivers, they don't need to care about this flag as all DMAs are handled through the kernel DMA API. For VFIO or similar drivers, they know how to manage the DMA themselves and set this flag so that the IOMMU layer will allow them to setup and manage their own I/O address space. If there is no better naming, I'd like to use this and add some comments for device drivers developers. Thanks a lot to Greg and Jason. Best regards, baolu 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 smtp3.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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3D481C4332F for ; Tue, 15 Feb 2022 03:08:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C5DD060D73; Tue, 15 Feb 2022 03:08:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fvtGBPCsGLk; Tue, 15 Feb 2022 03:08:23 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTPS id C6FF860A6B; Tue, 15 Feb 2022 03:08:22 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5438C001A; Tue, 15 Feb 2022 03:08:22 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5111CC000B for ; Tue, 15 Feb 2022 03:08:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3FC2160D51 for ; Tue, 15 Feb 2022 03:08:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbrVTV7VgKEo for ; Tue, 15 Feb 2022 03:08:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8757260A6B for ; Tue, 15 Feb 2022 03:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644894500; x=1676430500; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=geRpObVSkW/4BdCaIv62nRssJKtA31qUc5woj+F+Kyw=; b=lhmsE3wMFDeT0NAb1/ZzKUE5sEO98n6Up8eYGzfv1BPXDy4yVZzwD8zh Wtka4nv036ANpwIDcZetmqKT76YFc6DurXTUmhhL0U+525F7VRNaWNh2e 8udKdgKLK6VoJTg075kgFiFzxQq8iE+fpXBzPKuWAI157mx90eGLBlOBT cb5id9VCQoz1qPm5iWFVIp/uVfoHmty40Mg6UC0zia8WeDhsuKWmqwhzx WJgnQWKtLn2Ize6ku+4iyrucExPsqdyMUniwnkDuxvHzXmH5kT8MJv+vy oGM2lFL2J/OGlMAmRSIylidTMpfHvLkW95+GALN4Ebs0zxYhELKD/R65R w==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="230200714" X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="230200714" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 19:08:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="680812468" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by fmsmga001.fm.intel.com with ESMTP; 14 Feb 2022 19:08:13 -0800 Message-ID: Date: Tue, 15 Feb 2022 11:06:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 07/14] PCI: Add driver dma ownership management Content-Language: en-US To: Jason Gunthorpe , Greg Kroah-Hartman References: <20220104015644.2294354-1-baolu.lu@linux.intel.com> <20220104015644.2294354-8-baolu.lu@linux.intel.com> <20220214123842.GT4160@nvidia.com> <20220214131117.GW4160@nvidia.com> <20220214134356.GB929467@nvidia.com> From: Lu Baolu In-Reply-To: <20220214134356.GB929467@nvidia.com> Cc: Stuart Yoder , rafael@kernel.org, David Airlie , linux-pci@vger.kernel.org, Thierry Reding , Diana Craciun , Dmitry Osipenko , Will Deacon , Ashok Raj , Jonathan Hunter , Christoph Hellwig , Kevin Tian , Chaitanya Kulkarni , Alex Williamson , kvm@vger.kernel.org, Bjorn Helgaas , Dan Williams , Cornelia Huck , linux-kernel@vger.kernel.org, Li Yang , iommu@lists.linux-foundation.org, Jacob jun Pan , Daniel Vetter , Robin Murphy 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2/14/22 9:43 PM, Jason Gunthorpe wrote: > On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote: > >>> A driver that sets this flag can still decide to enable the dma API on >>> its own. eg tegra drivers do this. >> >> So you are just forcing the driver to manage this all on their own, so >> how about, "driver_managed_dma", or even shorter "managed_dma"? > > Yeah, I like "driver_managed_dma" alot, it captures the entire idea This makes a lot of sense. For most drivers, they don't need to care about this flag as all DMAs are handled through the kernel DMA API. For VFIO or similar drivers, they know how to manage the DMA themselves and set this flag so that the IOMMU layer will allow them to setup and manage their own I/O address space. If there is no better naming, I'd like to use this and add some comments for device drivers developers. Thanks a lot to Greg and Jason. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu