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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 341C8C77B7F for ; Thu, 26 Jun 2025 07:09:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B51E46B00B6; Thu, 26 Jun 2025 03:09:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B03006B00B7; Thu, 26 Jun 2025 03:09:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F1306B00B9; Thu, 26 Jun 2025 03:09:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8A2CB6B00B6 for ; Thu, 26 Jun 2025 03:09:41 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4198CBBF7B for ; Thu, 26 Jun 2025 07:09:41 +0000 (UTC) X-FDA: 83596676562.02.FC71DF3 Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by imf04.hostedemail.com (Postfix) with ESMTP id A449640010 for ; Thu, 26 Jun 2025 07:09:38 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=sPriQ8ui; spf=pass (imf04.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.11 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750921778; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xyLppUH/lMf7fJn9j7xcwn6KMqgflVkKpFIhS2f2+MA=; b=KiLCNqCNc0IZajDsR8D3jmZvuXJuVf0gYu3FRWIkA2+lEgzVcjl47wtAJpIHAoW1n0sp9W viqvTyia847hz05bI/vHSs2dXFN1W740MNf6c/vCNvc++sMDouV0kg7DJPH0z/wefQAYST 8mrWjiQLOC5Wb7au+9AnZ10ZrsOZMcA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750921778; a=rsa-sha256; cv=none; b=RkqJrkKpU4oDODhN1BqjYWX3SPx4gr8zofHC4n3bRY2xu6SVYGVJ55Hy59LliFhsKOUfCV uxGx3MkwmUXmZq4sKlUV9a07PDt4qPnZ8z6Kl025IfiNJax7BJloyBHD5PDgf/zRUxyMu+ M9IFT+d28d3fy/EqA9fJu4C3uQn6n6Q= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=sPriQ8ui; spf=pass (imf04.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.11 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20250626070936euoutp01e5b52a4d34da6c5eab3446330529787d~MhhQxBi0t1044810448euoutp01J for ; Thu, 26 Jun 2025 07:09:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250626070936euoutp01e5b52a4d34da6c5eab3446330529787d~MhhQxBi0t1044810448euoutp01J DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1750921776; bh=xyLppUH/lMf7fJn9j7xcwn6KMqgflVkKpFIhS2f2+MA=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=sPriQ8uiqRTWXPcO3E9/f9ZPX7sQvaGrCdH0LNTXFAQLXl+/dNgMT8IXqDvW4sQix uAGIkuKgIVCgcVqZ80TjHl0mKh4VheRZKFKJiYRv5M6+22JVK8LMaK4mcCv8VMYjf7 rF+v9C2sA3EYhlHM9F0DX/Z/xXySFBQPkBwJkAkQ= Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20250626070936eucas1p20acd53ee81a9da902daa980525b59c0a~MhhQYGeyR1269612696eucas1p2o; Thu, 26 Jun 2025 07:09:36 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250626070934eusmtip291f59cac2130b379c3567425bb69fabb~MhhPUlpnb2273122731eusmtip2o; Thu, 26 Jun 2025 07:09:34 +0000 (GMT) Message-ID: <1312ef41-1f7c-4b6a-9d04-aa49faaf9b17@samsung.com> Date: Thu, 26 Jun 2025 09:09:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 7/8] docs: dma-api: update streaming DMA API physical address constraints To: Petr Tesarik , Robin Murphy Cc: Bagas Sanjaya , Jonathan Corbet , Andrew Morton , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , "open list:DOCUMENTATION" , open list , "open list:MEMORY MANAGEMENT" , iommu@lists.linux.dev Content-Language: en-US From: Marek Szyprowski In-Reply-To: <20250626070602.3d42b607@mordecai.tesarici.cz> Content-Transfer-Encoding: 7bit X-CMS-MailID: 20250626070936eucas1p20acd53ee81a9da902daa980525b59c0a X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250626050612eucas1p166c9c423aa791a0f3f65ae6140e3e807 X-EPHeader: CA X-CMS-RootMailID: 20250626050612eucas1p166c9c423aa791a0f3f65ae6140e3e807 References: <20250624133923.1140421-1-ptesarik@suse.com> <20250624133923.1140421-8-ptesarik@suse.com> <20250626070602.3d42b607@mordecai.tesarici.cz> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A449640010 X-Stat-Signature: 71kdumji4gxn35wf33ugkxztq9dmziyt X-Rspam-User: X-HE-Tag: 1750921778-29855 X-HE-Meta: U2FsdGVkX1/pmDSNoSE5OFqknv3taGB6iAD2xeB6JRNAcMn32nF244iUE5dk72JVdwYJKnWEUUDtpDKvsJ8iMzqt46Y6hjL3NxxIitkWNowG8hgE7iZzcrd1NCJuP4ah1fSaZE4xp83jylentfq4SqVmqp6hM6mFFaGw+tUFnhlp5ChPD3U405v62nUnGZ/JVVucvLbT37h05LHHH3QszgrykEafEMfNPb1SfGtEYoJIK/TuV5c1Trci/2Yxoqm3fCkkQcS61e0qJiRg+c8p7lpKBqLOYksv6RZr5lLLNMUTv3NgW1wX+LDRdmBNJVOxQSep4GXZQ55giHrZ7zu1JlpjMvlC9dUdNhj4gtBDq+uPI5Hu4AalXWS59yHNGvdBqXQCesa+33VxxXTw+jkoUG7XIMjMjJmzWHJqUrZ7/wJaTO2bGqnXJvRgF+lj8fc1Prp81UZtnFhXSW02uvAey4TwC6/ZWS0PyFvF1RZ43fkt6Bvxyz/bglapgkB1506fKZo3UcAz0rJslCE4fsRGietam5tytjyhHEoIZqTU40ERoKq4hQRv3aYXmbeiryWhQUtrl3DdWJN0Os69Cf0AcqapwR7J2dCf/kuBPOJOlu+m5vjHykhAjAcHh8jpnF9CqQ7PzN64Q+LjQl9/iHrtHalFd3LJLEqnbswIMBcb/kPwEc7ytifFF+Ea/JB8vPh/EcoosaQJ+GSBbperQo82UXXjgwRF153OrlNWi17fPS0ulnXfUMMQwddn5n0gW6HBEJyzi/sZY6embrQJV0dh6s9mabN4+omHsPwAcDQIyXAB0e7qNSGDUH32/5vL83JgbRKJJDr8xn6kZcvk/NXz/mcFzka/CXs+QfgkR08r3jSX1waty0pXAObnWLiEkvH6mPKy2taB2Ra79U90juUn88aonwOjgYjvGupTAkQPGPCC4+TtxJi9R8N6uphJ8sBGZtks0BNJBntPebD0LIe 1WIs6o+Z GPH1MCpoWNdkaDB/lHM3Ff0p/mW20KPJKiCFQrmw5BROPHkpipXmcviGDzTgE87unMOUcxa2a1rkE4P6tfE9JJQjkgC/v5W9Rb2wv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 26.06.2025 07:06, Petr Tesarik wrote: > On Thu, 26 Jun 2025 08:49:17 +0700 > Bagas Sanjaya wrote: > >> On Tue, Jun 24, 2025 at 03:39:22PM +0200, Petr Tesarik wrote: >>> diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst >>> index cd432996949c..65132ec88104 100644 >>> --- a/Documentation/core-api/dma-api.rst >>> +++ b/Documentation/core-api/dma-api.rst >>> @@ -210,18 +210,12 @@ DMA_BIDIRECTIONAL direction isn't known >>> this API should be obtained from sources which guarantee it to be >>> physically contiguous (like kmalloc). >>> >>> - Further, the DMA address of the memory must be within the dma_mask of >>> - the device. To ensure that the memory allocated by kmalloc is within >>> - the dma_mask, the driver may specify various platform-dependent flags >>> - to restrict the DMA address range of the allocation (e.g., on x86, >>> - GFP_DMA guarantees to be within the first 16MB of available DMA >>> - addresses, as required by ISA devices). >>> - >>> - Note also that the above constraints on physical contiguity and >>> - dma_mask may not apply if the platform has an IOMMU (a device which >>> - maps an I/O DMA address to a physical memory address). However, to be >>> - portable, device driver writers may *not* assume that such an IOMMU >>> - exists. >>> + Mapping may also fail if the memory is not within the DMA mask of the >>> + device. However, this constraint does not apply if the platform has >>> + an IOMMU (a device which maps an I/O DMA address to a physical memory >>> + address), or the kernel is configured with SWIOTLB (bounce buffers). >>> + It is reasonable to assume that at least one of these mechanisms >>> + allows streaming DMA to any physical address. > Now I realize this last sentence may be contentious... > > @Marek, @Robin Do you agree that device drivers should not be concerned > about the physical address of a buffer passed to the streaming DMA API? > > I mean, are there any real-world systems with: > * some RAM that is not DMA-addressable, > * no IOMMU, > * CONFIG_SWIOTLB is not set? > > FWIW if _I_ received a bug report that a device driver fails to submit > I/O on such a system, I would politely explain the reporter that their > kernel is misconfigured, and they should enable CONFIG_SWIOTLB. What about the systems with legacy 16/24bit ZONE_DMA (i.e. ISA bus)? AFAIR they don't use SWIOTLB and probably they won't be able to use streaming DMA API for all system RAM. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland