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 7F338C38150 for ; Wed, 10 Jul 2024 06:22:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9CB76B0088; Wed, 10 Jul 2024 02:22:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4BB66B0089; Wed, 10 Jul 2024 02:22:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B39D46B008A; Wed, 10 Jul 2024 02:22:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 950416B0088 for ; Wed, 10 Jul 2024 02:22:20 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 42319A1B50 for ; Wed, 10 Jul 2024 06:22:20 +0000 (UTC) X-FDA: 82322848440.18.B3E1039 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf25.hostedemail.com (Postfix) with ESMTP id 5CF77A0012 for ; Wed, 10 Jul 2024 06:22:18 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720592507; 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; bh=is3clyWtBV4BLw0NVVUMoS+sRKP5gH+whCcYTcmsk4I=; b=RvrFfi0aYRUd25WTVzOPjF1cyXH7N4lzgzX9dhIA8zHnYXixKtpd4hs0NLCogn8eNS7pNw 2lhadJhl83r4bDLSr67Giv9AvT+xrWPVKD6Regb9sc91QlipuSEtI1OwqwQ1kxeT9Ozmh3 4DpGritli2O1sNB4YFLSUlybO7NSkEQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720592507; a=rsa-sha256; cv=none; b=zPB95ZzZ3VwJHYIpnt8yP81odYs1SMn0AxuviFyNw/M6ZDEVmL0AeSe03oVjcBITW/Dz4b RGpMsv4rOEu4Ch3PyFC2l7l771EfvTwJNaNEmz2WD2xlpE3OegSBTAfG66I3iHJw5an/t2 I18TSY4BA3YkkBFBz8ASATsbd8h7L+s= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none Received: by verein.lst.de (Postfix, from userid 2407) id ACBCC227A87; Wed, 10 Jul 2024 08:22:12 +0200 (CEST) Date: Wed, 10 Jul 2024 08:22:12 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Christoph Hellwig , Leon Romanovsky , Jens Axboe , Robin Murphy , Joerg Roedel , Will Deacon , Keith Busch , "Zeng, Oak" , Chaitanya Kulkarni , Sagi Grimberg , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , linux-block@vger.kernel.org, linux-kernel@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 Subject: Re: [RFC PATCH v1 00/18] Provide a new two step DMA API mapping API Message-ID: <20240710062212.GA25895@lst.de> References: <20240705063910.GA12337@lst.de> <20240708235721.GF14050@ziepe.ca> <20240709062015.GB16180@lst.de> <20240709190320.GN14050@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240709190320.GN14050@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5CF77A0012 X-Stat-Signature: sf5wf5qxtmr5bofdzn4gexarx948yp3i X-HE-Tag: 1720592538-34723 X-HE-Meta: U2FsdGVkX18jIRM/z5gf6BheahQb6npgKxwGkXim2ottX3nlz8f621VUmxr2TR/cLCXnOXmaReFdfSHP4yv4IXKjQPf3Xs32mPTSMFdIIE22H4XfBdQYm8YBIA63H+4ryaMCDTYvSKSKfCF3Pge9lCjhfmjoVKuWOWfSSHpfwRPjL36DUJdoTwezJzKIPp4PWsne9v9sE4Ew5+Dj64Oe8C3QMaR4GkdQX7ohCHbE9kOvMzoVy6osgt4AOa3PW+Jj/qyXGtaL2nCI5aQMI8v7rah3vYsCDbykXbCE9XpQ6GRhQ80ww8IskAQEfDjdD6u/6lq5pYfLehNUo2B01Tg+g1G4FkBsbCwH3pyNhGpI2Q+XmX7rpH94BKb+oFwPXDP3ubO/JPqW+qerIkNkib2uzTh7tY182ApY8F1guJEkrOOaMopUJ7LAQHUcjtBmAGA38kHrffOl7QDb/JoKfCHPiyhZT5IOWnXP2rMqxlpaJ2pT/p0UM/D8CCywYE4hpCVZyW58P8NlX+fflIyH90MKlzLdHeV6AzGrpau6Z9peBkFeOP8R3j1wAzrtMoFbaqXmqFAXmzyw1mTYeVTsgzjR+HW54Z1LwuxDq86owdp1DK+Cj6tR23svFpz/EfMF2SR6yO/+m0bGWnnPP7DoGmIFP2gjbi/6iJpqiSCjfb4wOlA44PsgbvKaNpDg7HI5Lnqhj9xBFn8psMsxDdbHcIso9LZGCCnjq2hwKgZoOf9mWG0zgCklOydmUb9ItLwC7P00Ti64Rt9fdNTXEinuVqq6vN4mSqlY03ojBgfEZBJShxmeUwtFMEWlHR32ezdeMoS8rPRxCLV1EqMeqyL84l/4cNpUMgEY6NFipzbmZ8Nj4VadSs0QC9NjpRsvqB1TXanKOjNwrKeDglk6K0NbHaMYI5+1bQD2h0mjvqcPa/vfwEF9P/+PFv/5hsrZY3fbYcmChIu3u1qBdDCIpfQtMrJ 5++MtpJN coUatM/B2cVw557WEanPiKRxB3Z1mZJ8OLc8a8rH99bcYlo5fyYImQU2DRY3BJR57B0wrY70PmisP2nk= 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 Tue, Jul 09, 2024 at 04:03:20PM -0300, Jason Gunthorpe wrote: > > Except for the powerpc bypass IOMMU or not is a global decision, > > and the bypass is per I/O. So I'm not sure what else you want there? > > For P2P we know if the DMA will go through the IOMMU or not based on > the PCIe fabric path between the initiator (the one doing the DMA) and > the target (the one providing the MMIO memory). Oh, yes. So effectively you are asking if we can arbitrarily mix P2P sources in a single map request. I think the only sane answer from the iommu/dma subsystem perspective is: hell no. But that means the upper layer need to split at such a boundary. E.g. get_user_pages needs to look at this and stop at the boundary, leaving the rest to the next call. For the block layer just having one kind per BIO is fine right now, although I could see use cases where people would want to combine them. We can probably defer that until it is needed, though.