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 CB18CC4167B for ; Tue, 28 Nov 2023 23:08:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6469E8D000F; Tue, 28 Nov 2023 18:08:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CF9F8D0001; Tue, 28 Nov 2023 18:08:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4732E8D000F; Tue, 28 Nov 2023 18:08:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 37A558D0001 for ; Tue, 28 Nov 2023 18:08:51 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 026E312035A for ; Tue, 28 Nov 2023 23:08:50 +0000 (UTC) X-FDA: 81508904862.21.28B8991 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf04.hostedemail.com (Postfix) with ESMTP id 4F4A04001C for ; Tue, 28 Nov 2023 23:08:49 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=TqmldDv1; dmarc=none; spf=pass (imf04.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701212929; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZwfH1boRaqUSm7vYG/zdQBuuZhpN21nmfcJNTWlLUDE=; b=KFztwwFbxfigl9dUpy5zaluoQXNMcpmTRYeCy/XuTKwoj0GD02xjPqDAZUeSfDER+UmjeJ yjUifPlceTH42qt4zAHapJTu/uzRNvgsXH6wrhVCd7FC7LuUVWsDHdkjWyMgd3A713+4db ms9oZlQ2t5pdMMh+oFm/NgYzEY30GXM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=TqmldDv1; dmarc=none; spf=pass (imf04.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701212929; a=rsa-sha256; cv=none; b=fokAD5ydQdkL9jzSTuGTh8SlOn0cktfRIgCMVM2dweivzQFQBdKCg1tekZkAOhtUoJkkNV Rz2cp6mTuRvd1DUDwwil4Z0ByuuiLBfD3pJgY2fKLHrjFwaOl9U0kgl5dwZII866WGhLY5 9BOBHX87fbGT7Aq/s8fAvipNMEkOij4= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-423c944352fso13595561cf.3 for ; Tue, 28 Nov 2023 15:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1701212928; x=1701817728; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZwfH1boRaqUSm7vYG/zdQBuuZhpN21nmfcJNTWlLUDE=; b=TqmldDv14Z7QBm9OgRX+A8KTHCcQ1ffP130DtZ9EeXbtOjsHInd8i6LQmwaimwA2/5 l216uZNxKGT75X/jz6FHcyUh312/5aFWxCcXl/lo7deIaKJesgI7lpJ2IZqlj4vnu4Qu SuHSE2ruUvpQ89sdAimI31pp/KhiSVNY6EhJhXuvgorMtiZYg+Z9R8JfO+1PCt0XN5qh xa5P3O/Wqypq2ZY1DYE9Ica28ZYfcUqS68BXjVh/mBII43xnh50BphRQ4v1MrLem8mGZ Nka8enYaakvM8Gdi5JnYlWq5mgTM3i1FiKtSL0EclCk+3W+0Mc4NihaqQhSOSFmieERg F6bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701212928; x=1701817728; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZwfH1boRaqUSm7vYG/zdQBuuZhpN21nmfcJNTWlLUDE=; b=ns7jTlKDschg0qJtFiL3KigOrs3wX07YM8y/tKOWuPsB1gOxxL8UU0iD+S29WfBt4s ZtUKtP3BqosJZJaf4Jfzp3LF3rUulsXRQx6+hH5wPcmhZ91DkTJEPx0W6X2jJIKb+pXl Nw/RJaq+tsVYNRwt1gMK2eIeVDjOS+RawK3b7wmknxzFfE/FvGG1gmTFgmKzk6Hfac6y WrYW+j7A2lsDy85X6l2t8JRsgq3XEI8DwgWwxQcboIjLcOU3GP+Jp91Dwmx4H+3TBaBT DivneBPlCDoaZG7h4fxpD8ALHAyD19QDrPBrIV0BZHYEywuKBrJUVQAajBZh9E7KBrrG Z0cg== X-Gm-Message-State: AOJu0YyiQkcKi8rYSMK8lPmhLcZON0glOKS9OTFGdD+sMJXwnPaAjQeV MaaK/xDlGo5STn782mCJ9Ycvs+LD7qdJryT7jZK7Ew== X-Google-Smtp-Source: AGHT+IH+DSzeg4H32kbSmeDdX42LwmFTBbiExz1cQ9Spo9pVMTh9OFSxf1oX9/Sr0tuUo1qYELK4l02okd8aqJLSMys= X-Received: by 2002:a05:622a:d2:b0:423:7f91:3a17 with SMTP id p18-20020a05622a00d200b004237f913a17mr22124861qtw.21.1701212928489; Tue, 28 Nov 2023 15:08:48 -0800 (PST) MIME-Version: 1.0 References: <20231128204938.1453583-1-pasha.tatashin@soleen.com> <20231128204938.1453583-7-pasha.tatashin@soleen.com> <79c397ee-b71b-470e-9184-401b4b96a0d2@arm.com> In-Reply-To: <79c397ee-b71b-470e-9184-401b4b96a0d2@arm.com> From: Pasha Tatashin Date: Tue, 28 Nov 2023 18:08:11 -0500 Message-ID: Subject: Re: [PATCH 06/16] iommu/dma: use page allocation function provided by iommu-pages.h To: Robin Murphy Cc: akpm@linux-foundation.org, alex.williamson@redhat.com, alim.akhtar@samsung.com, alyssa@rosenzweig.io, asahi@lists.linux.dev, baolu.lu@linux.intel.com, bhelgaas@google.com, cgroups@vger.kernel.org, corbet@lwn.net, david@redhat.com, dwmw2@infradead.org, hannes@cmpxchg.org, heiko@sntech.de, iommu@lists.linux.dev, jasowang@redhat.com, jernej.skrabec@gmail.com, jgg@ziepe.ca, jonathanh@nvidia.com, joro@8bytes.org, kevin.tian@intel.com, krzysztof.kozlowski@linaro.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, lizefan.x@bytedance.com, marcan@marcan.st, mhiramat@kernel.org, mst@redhat.com, m.szyprowski@samsung.com, netdev@vger.kernel.org, paulmck@kernel.org, rdunlap@infradead.org, samuel@sholland.org, suravee.suthikulpanit@amd.com, sven@svenpeter.dev, thierry.reding@gmail.com, tj@kernel.org, tomas.mudrunka@gmail.com, vdumpa@nvidia.com, virtualization@lists.linux.dev, wens@csie.org, will@kernel.org, yu-cheng.yu@intel.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4F4A04001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: omg13j8zq9bxgz8ri1dediywqdyw6crf X-HE-Tag: 1701212929-940866 X-HE-Meta: U2FsdGVkX19NGv5KS96z2G9IKQnOStnYnPEcu1BVDZk0QU4F/XcBLPTVisSIYSBPvBqwXgClWXs1z+4mtZ+eW/1HRtNBru+ITo0IP7ybYpdDh9aEZi0cCRoMH4nOPzR4N+XvUEsPkxFTFoMIzoqbk5cv4UE1TbCl58MwF9bnWt79CqRvVWxVP8pgeKZc97oDNs8WTT0J/z3UprDejZXuChRFCBv899dKa1d20qtnYpknWhMUmGqnmhEYUotn2FrTekFZIZr2SfiT5fDiEFGdqVZiJwMrx9NgBtDt7ApNb7wEl7/K3genOZwhfArDQ+ItmTPzFbL4fOs39j/yNfziNM60zPxr1o4GLZTRluedGD0FuvjZ9t3okekH+24C7HmpMjI6EMoDMr8Jmsx7j8iNXLe9x0Qbs6GOkB2Te+MYlRRrsQz4lhBb8wfnkVhHVT6E1uFjGHqNSgKMlWiqmE6dnBTh91DF537ORKep2Py8iesrLGkQium3jKx7Ict2kX0T6ha1oK2wQIIHfxFsLAeRn3j64chiaFYIaZ9ttoIxrKna6pvsfZ7vgEpcmyYe8gDj41ytVU+yN02ftw95Fe+9rJgC0ciKg4MIF4W+DFB51bC9jgSjYcpSPts5XNtLzAC0c4BspBD7DhP6VoMbI6G4IfspeNLW9CMNm5NQAxy1s0GNQVBGCE8g6ycYgqSGh/07O+v5XHDIvww0jv/F5+And+pSLQRrTqRgBR9xQiSit6Hnt8Dw6qszKQAQtLk40BH/klasH0HJdOB+VGEsfK/sA5CuUvG8ifGIao2jbtbUkf1jUdGuPiewF1/rgKXuWMEc5kZYsxinZwAL15Ime9sUxgI5Np7cXKVKZnwcE7SYQUAtLlrBXfLuDSSo9I93yjsy6y5pnXhxsNDy77Xyz7KZe7pKWKdhXPrTfARyUktbNDVupXrw9nPRIIGSVZqJWXFpmbMpwHaNJKoaW7nuKvQ WudwdKTG u9/b8jTPUnPG4VTN9/rUj6XXPrZslecLQv6+11EeY0DAPxbZxeauERy1/2v4Vvo3N2Q56TmQO1aNBtzDRZK9XcBwniL2r0PU2HHqfaK1pTloB4Ne3V3lClaTzpTc+EX9JpdrjReYjzbezimw0WN5Kov8VyBYytgrhmesZp5im+s9fBNTo8BLiLjGcQFFhllmfl5YDswo9/b0ogs2n1CfTIVPgCQsSRBN+QJrUsDZhtOPOOR1LZDqIVFhkaPD9gLf9hR7EkIAnPvb12kE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001669, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > This is true, however, we want to account and observe the pages > > allocated by IOMMU subsystem for DMA buffers, as they are essentially > > unmovable locked pages. Should we separate IOMMU memory from KVM > > memory all together and add another field to /proc/meminfo, something > > like "iommu -> iommu pagetable and dma memory", or do we want to > > export DMA memory separately from IOMMU page tables? > > These are not allocated by "the IOMMU subsystem", they are allocated by > the DMA API. Even if you want to claim that a driver pinning memory via > iommu_dma_ops is somehow different from the same driver pinning the same > amount of memory via dma-direct when iommu.passthrough=1, it's still > nonsense because you're failing to account the pages which iommu_dma_ops > gets from CMA, dma_common_alloc_pages(), dynamic SWIOTLB, the various > pools, and so on. I see, IOMMU variants are used only for discontiguous allocations, and the common ones are defined outside of driver/iommu. Alright, I can remove all the changes for all no-page table related IOMMU allocations. Pasha