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 3B677C3DA45 for ; Sat, 13 Jul 2024 05:24:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E06A6B007B; Sat, 13 Jul 2024 01:24:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7921E6B0085; Sat, 13 Jul 2024 01:24:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6591C6B0088; Sat, 13 Jul 2024 01:24:18 -0400 (EDT) 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 48A076B007B for ; Sat, 13 Jul 2024 01:24:18 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 04213C0DD3 for ; Sat, 13 Jul 2024 05:24:17 +0000 (UTC) X-FDA: 82333588596.09.60A3E8F Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf24.hostedemail.com (Postfix) with ESMTP id 08C3B180005 for ; Sat, 13 Jul 2024 05:24:15 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720848217; 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=3TDikD6pp2ycIS8/CpN/B+ZNO+YZyR7OgGYextyu2fo=; b=l3T9DUUOQLH16mblgYGXgJuHeqyEfTtLWlbiZh8BVO+5f9Zk33qyP8HtAjGbtzocvR5gEB l34NeWYBqkJ/wmj3ogehg+wDDOxWbjC5c0UbkvXhuFP6s/5o4sVs4K7LWiIyQ8efhZxSL0 1XVsVHfG8znGHUfmfQGZnpWdlN+9QKU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720848217; a=rsa-sha256; cv=none; b=Kb1/tMlUMjwRNeG97Tr5J8ZzniZX0hAuBynkRKO1M3bi5owCqGoNDDSheyMwPMlSpn2qNZ lUrum1afrUVMLPqR8kVkGAzda9HlH/p9g2mBakYlNRfcko8/uYJnDypUVxcGWxPEg09NV5 DWighhGXQ0a2j5qHS7itBizKORENq24= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 5CE8768B05; Sat, 13 Jul 2024 07:24:09 +0200 (CEST) Date: Sat, 13 Jul 2024 07:24:08 +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: <20240713052408.GA25890@lst.de> References: <20240705063910.GA12337@lst.de> <20240708235721.GF14050@ziepe.ca> <20240709062015.GB16180@lst.de> <20240709190320.GN14050@ziepe.ca> <20240710062212.GA25895@lst.de> <20240711232917.GR14050@ziepe.ca> <20240712045422.GA4774@lst.de> <20240712124237.GX14050@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240712124237.GX14050@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 08C3B180005 X-Stat-Signature: 5qbqpmspp63ddd6ro9tptjxors15etbp X-Rspam-User: X-HE-Tag: 1720848255-845401 X-HE-Meta: U2FsdGVkX1+hIUiNQfOmzjNVbiqqny6JeuzBAl5z70uSH6ggMixA2WPQpZP3+ODr7SFGuGJdo/DZ1YgXiIXM/O7KQxqxv/2YGB/HHVy9LQkRbkYk0YIcJ6cDnjbjHBs8zWaN/epqKrxtM9B6gE197v7k+t/+Do6YzslbuyPkjh8MMORRh5mVCsIOeYWY0/5JwhdIUdyDP3F029jG8JllUzMDtC/deqYh1Q0iaoou5IxM3YUDbEtihEbrYveVcrt9ZLLZk5jNCLnlE1nLbELpU0WFZQl5ry+lDv91F0LXTu3gk+WKMCwL7kSBpYDfPC6adB6kI2b/+Uzi1jbi+UsZIVOXjKenmjRfEoD6KoN6TexytR206HyAjJyOJzOfZsOz+Pu1mmhC8HOg7VleTr9l3SfpB8wdOP3H1DqvFMfHzzg3ZirsF4P/rIU0vnBzczFSha6HoLQHQXsF3Hpb22v7mjpAVwS0wXZp8u9N6LUSroEgxnTMmqwd9zWmyFyqtKzZxSmaizdklmoFEAE2OTLQVJC4xrEDJRTx2n0yajOcHax51nTkT/JO32bghaYD+tIfxyayadqUuINvR1/5j8mip7QaKXwBYDkilwZx0j3DdiIMtZrK3PjTlHn/S5EGgdy8WFKKruO4QLnebLoZB19mIOaaKAAPIlT9Y2IcupEyh+KHNidYTiRK2sGJjlBF8k5FBjyyukfpEQJLzDppYa3T6WAWWGLfD2iWSp69H3PBrM2ulMFwfd9L2Hf9F+PYbLsSC+81nfnP2pVeCfyGLtbJw+ce0Fbav6HhojcC1ut0Op4UX8tYt2d6IDFSTn2ssDEymTp23IjJuHgZsHf/7Du8WnKUxQ6o0uRl0zVY+n1t3RTIJd0nWr7KNPIe5339EB/EQk5ymV/Wogbdk6TYZKFsu/tKbtWx5ikcVnc6+3Ajjfdy0gQgsIfk8xvf9vUyvHLuc70RfKaMmoZw/5SJGts NbP7fYYf fKU0UPJ5oyjzr6e2UWN0hY7ZNGIHWA6DExNuO8FRxYlR9cdWvuIH7nfGoAaggv4mva4sOvVkbivg/as0= 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 Fri, Jul 12, 2024 at 09:42:37AM -0300, Jason Gunthorpe wrote: > On Fri, Jul 12, 2024 at 06:54:22AM +0200, Christoph Hellwig wrote: > > > This is all purely hypothetical, and I'm happy to just check for it > > and reject it for it now. > > I do know a patch set is cooking to allow mixing ZONE_DEVICE P2P and > anon memory in the same VMA ala HMM with transparent migration of > ZONE_DEVICE to anon. > > In this situation userspace will be generating IO with no idea about > any P2P/!P2P boundaries. Yes. And as said from the beginning of these discussion I think the right way is to change the gup code so that for a single call to get/pin_user_pages it always returns either only P2P pages or non-P2P pages only, with the FOLL_PCI_P2PDMA just allowing P2P pages at all. Similarly they could easily just return one kind of P2P pages per call only.