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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B281C433EF for ; Tue, 5 Jul 2022 16:50:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 029604092B; Tue, 5 Jul 2022 16:50:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 029604092B X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK_LvnoDE7Er; Tue, 5 Jul 2022 16:50:47 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id E3486408D3; Tue, 5 Jul 2022 16:50:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E3486408D3 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B32B6C0032; Tue, 5 Jul 2022 16:50:46 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E3E5C002D for ; Tue, 5 Jul 2022 16:50:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1A68C4015D for ; Tue, 5 Jul 2022 16:50:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1A68C4015D X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIXH31TGA42X for ; Tue, 5 Jul 2022 16:50:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 77E54400A8 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by smtp2.osuosl.org (Postfix) with ESMTPS id 77E54400A8 for ; Tue, 5 Jul 2022 16:50:45 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id C89A168AA6; Tue, 5 Jul 2022 18:50:39 +0200 (CEST) Date: Tue, 5 Jul 2022 18:50:39 +0200 From: Christoph Hellwig To: Logan Gunthorpe Subject: Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem() Message-ID: <20220705165039.GB14566@lst.de> References: <20220615161233.17527-21-logang@deltatee.com> <20220629064854.GD17576@lst.de> <99242789-66a6-bbd2-b56a-e47891f4522e@deltatee.com> <20220629175906.GU23621@ziepe.ca> <20220705075108.GB17451@lst.de> <20220705135102.GE23621@ziepe.ca> <20220705161240.GB13721@lst.de> <20220705164315.GB14484@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: linux-pci@vger.kernel.org, Dave Hansen , linux-nvme@lists.infradead.org, Stephen Bates , linux-mm@kvack.org, Jason Ekstrand , Ira Weiny , Christoph Hellwig , Minturn Dave B , Martin Oliveira , Matthew Wilcox , Jason Gunthorpe , Chaitanya Kulkarni , Bjorn Helgaas , Daniel Vetter , Ralph Campbell , John Hubbard , linux-block@vger.kernel.org, Bjorn Helgaas , Dan Williams , Xiong Jianxin , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , Christian =?iso-8859-1?Q?K=F6nig?= X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" [note for the newcomers, this is about allowing mmap()ing the PCIe P2P memory from the generic PCI P2P code through sysfs, and more importantly how to revoke it on device removal] On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: > We might be able to. I'm not sure. I'll have to figure out how to find > that inode from the p2pdma code. I haven't found an obvious interface to > do that. I think the right way to approach this would be a new sysfs API that internally calls unmap_mapping_range internally instead of exposing the inode. I suspect that might actually be the right thing to do for iomem_inode as well. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu