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 DD512C02180 for ; Wed, 15 Jan 2025 07:27:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5910A6B007B; Wed, 15 Jan 2025 02:27:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 51A146B0082; Wed, 15 Jan 2025 02:27:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9976B0083; Wed, 15 Jan 2025 02:27:26 -0500 (EST) 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 19ECC6B007B for ; Wed, 15 Jan 2025 02:27:26 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B1E63141075 for ; Wed, 15 Jan 2025 07:27:25 +0000 (UTC) X-FDA: 83008855650.25.3465DC3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id 1852540008 for ; Wed, 15 Jan 2025 07:27:23 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PlEsLImC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of leon@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=leon@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736926044; a=rsa-sha256; cv=none; b=wHA3E+aCZUfyRk6xDh5YLsiUfvurAfvwCUn+z4MO5uJBUG4R3W5NmyPhL5B504DpQmTE5E x0hLRZGcbzbMYyzdZMVlOBuBjJnvaWF90XUHOs0xkAupzKPEe7Z5HssKtcdPgZAIUFaSbG VvMiqvGxTcXPJ4ylI/53gv4k6lLKuFY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PlEsLImC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of leon@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=leon@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736926044; 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=UEtqWmZnkkmJQ8Gt5KtEQ/SLZwf8ufb8M7nJ1GLm6xY=; b=gIbgIfzpFCm1YBMyvLDQ21cu4GgbqdaK4f1TCRgsp7EyMrrRKAwQUGPCRPYjF9h/5D+Jtq UBnUl6QeDkSwJaQSuX6ILnkdRMBq9Adl48yBGYQMZp0mfC526DdIYcWyRNrXB6t5T7Se8y eAFFHs1ty+1ARlyfI2PfJHPRz6npH58= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 15F36A41729; Wed, 15 Jan 2025 07:25:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FD41C4CEDF; Wed, 15 Jan 2025 07:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736926042; bh=W+JWGoU6jLFwbe+ZoYGQcxjcZ17AGd0C8/odV+o/TLM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PlEsLImCwnYqAoqms0P20DW62uLfIgjKyzptCpjG5UVIUXYCrzVmwk7m0oi/eJDWg i7D1HOkxJZnKKnh0C+5xD+1X+uFQNGWJ1iZOiw1yU9Qcb7+5dh8ogtNN/k0QCZgCZJ TyKE1gNFh1Eh9kiL7Z6WnV63cZKl9hwNUc02tBxWp3qPFnFGIDvADP4ssiUBQEzGog BSgaFn4z3ohejNw+thnAgwWyLPajfW6rH21UYgVzsz5O38cma/CfLRJS2ZPPOsw53e j7/TVSSizkDLGNS26gONx2q0vAi+LG3NkSnHwl81L1TUxhDeOkKbBvsH1CHdaPabMt mR77nKXe/gODQ== Date: Wed, 15 Jan 2025 09:27:18 +0200 From: Leon Romanovsky To: Christoph Hellwig Cc: Robin Murphy , Jens Axboe , Jason Gunthorpe , Joerg Roedel , Will Deacon , Sagi Grimberg , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, Randy Dunlap Subject: Re: [PATCH v5 07/17] dma-mapping: Implement link/unlink ranges API Message-ID: <20250115072718.GJ3146852@unreal> References: <20250115062628.GA29782@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250115062628.GA29782@lst.de> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1852540008 X-Stat-Signature: gke7j5jm9nbhgpowtrax6bidz5htfcan X-Rspam-User: X-HE-Tag: 1736926043-220771 X-HE-Meta: U2FsdGVkX18/tGYkGLQrHWxB0nXhneashm2wSLRcH2GM9qq0Y8JGbflo9tkwt6cG8rn24AnrSdzQxc/SJyTDD+vhai5ajwROQ5+TIxuDiN1sl8cL3LZNVkvDTHfI4Tr9G/r81ScY1hR78mz+LHC6TiM28vUivt9GVU0dhmVL3Y1BHcoOrdaCkaB+nxM3e1s+F7wlb356IEiAuKZMGA+YeCa5vSMbzuNdaC4wqMq+s0Yn5lFJNaar7vlY/Wj4dD7ozYnciDmusV5YWwENIB6pZ/HEbva+iSVaEWjVJGDYaleG/a6ftuXzfUjjkgaWZ/MnVdJmi8Px0Kb51k1hXTg4O8m1V8qSiB3j28r9mnZ2pBK4u/GL9D+0EL6xeA06MYmkS0DUVHcHMsdObVzG1ksILDug9BCq+srzmn1OJufNowaf4wdzMDrbbQLNL2lLbBvqfm3hhCMDBqQxg5JRS167mM9rFXzhNvgZvkOii00af8vplLCMi82b5II0uw+U3cd5IilRFDtcNVWAXD8Taptg2sg4tI2Pv9vRoRk6hl9kDx4YV+ZXkJfFLpvKr+MRm3rsnhpKkch1WAL3uKQqQ0M6tlj1j4E44CJo0GWgPLTszagb5QJb1qOLgljlQhb4Rs2j7eRZtmkzNeH5uQ2Bk5nKZ3b82aeAHE6G5aPHqc3nTZuMlJ6VH1prRIKb5EZag0fnpT50cYV0PLqeCvwUXIlN2ewysh3EbQvWMM4G9OvpPSv59Uy2Rm7bnxARHzxQS3bTyS4qNoNOPFKydCxJwz+TiLZF0Wfyn3H0rqImwO3Ou9L31hL1Gk2TRRHuN5smMm38OOSNbJ1o2+F768QFWnUp/yOs1IN7LgqAE80f/O0YseghkbjWtk/PBsJ7cxmuKQfFE/nRGTigMp4wKBgX7QKQ6d8h8M5BDezjS4gcpR0BOyK7t33o/BLg5gGjJ8+bnKOqmpK1A4OKlS4liBGdo3f PdCg4uSM UdlOUcI2BLgioyrepEpRm4I28TsO0YinRKQ/d5N25JkSn1tmCG5gmvQG8sOMAmGR/JQreffSHTjZlyI0OCXA2TZMRiBkUNDxV5MhkaLL9l0aszJ808JseujmkPG8ibyHnJTkbXg685r3CGIRrVYwtzDSATKBcTkrX8T1P4v2ywykaEKW7YZ0EP/lzGCU1V4EyvWqzXWifzbV+GKtr0e4mqCOuj/bzTqs0iPcmtgSwq5ORr7Pu29cBfid8DqZmUqU3ahD1 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 Wed, Jan 15, 2025 at 07:26:28AM +0100, Christoph Hellwig wrote: > On Tue, Jan 14, 2025 at 08:50:35PM +0000, Robin Murphy wrote: <...> > >> + if (dev_use_swiotlb(dev, size, dir) && iova_offset(iovad, phys | size)) > > > > Again, why are we supporting non-granule-aligned mappings in the middle of > > a range when the documentation explicitly says not to? > > It's not trying to support that, but checking that this is guaranteed > to be the last one is harder than handling it like this. If you have > a suggestion for better checks that would be very welcome. > > >> + if (!dev_is_dma_coherent(dev) && > >> + !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) > >> + arch_sync_dma_for_cpu(phys, len, dir); > > > > Hmm, how do attrs even work for a bulk unlink/destroy when the individual > > mappings could have been linked with different values? > > They shouldn't. Just like randomly mixing flags doesn't work for the > existing APIs. > > > (So no, irrespective of how conceptually horrid it is, clearly it's not > > even functionally viable to open-code abuse of DMA_ATTR_SKIP_CPU_SYNC in > > callers to attempt to work around P2P mappings...) > > What do you mean with "work around"? I guess Leon added it to the hmm > code based on previous feedback, but I still don't think any of our P2P > infrastructure works reliably with non-coherent devices as > iommu_dma_map_sg gets this wrong. So despite the earlier comments I > suspect this should stick to the state of the art even if that is broken. Right, I was asked to set DMA_ATTR_SKIP_CPU_SYNC for PCI_P2PDMA_MAP_THRU_HOST_BRIDGE case. ... 752 case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE: 753 attrs |= DMA_ATTR_SKIP_CPU_SYNC; 754 pfns[idx] |= HMM_PFN_P2PDMA; 755 break; At this stage, we didn't change DMA/IOMMU previous behaviour and if it was broken for certain flows, it stays to be broken after this series too. Thanks