From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DE69121939304 for ; Mon, 3 Apr 2017 14:44:33 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f193so142571967oib.2 for ; Mon, 03 Apr 2017 14:44:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> From: Dan Williams Date: Mon, 3 Apr 2017 14:44:32 -0700 Message-ID: Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Logan Gunthorpe Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Christoph Hellwig , Max Gurtovoy , Christoph Hellwig , Jason Gunthorpe List-ID: On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers attempt to access > iomem directly through the sgl. > > I'd also probably create a p2pmem_alloc_sgl helper function so driver > writers wouldn't have to mess with sg_set_iomem_page. > > With all that in place, it should be relatively safe for drivers to > implement p2pmem even though we'd still technically be violating the > __iomem boundary in some places. Just reacting to this mail, I still haven't had a chance to take a look at the rest of the series. The pfn_t type was invented to carry extra type and page lookup information about the memory behind a given pfn. At first glance that seems a more natural place to carry an indication that this is an "I/O" pfn. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. Date: Mon, 3 Apr 2017 14:44:32 -0700 Message-ID: References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <445bc352-75d7-438f-96ef-c2411215628d-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Logan Gunthorpe Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Steve Wise , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig List-Id: linux-rdma@vger.kernel.org On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers attempt to access > iomem directly through the sgl. > > I'd also probably create a p2pmem_alloc_sgl helper function so driver > writers wouldn't have to mess with sg_set_iomem_page. > > With all that in place, it should be relatively safe for drivers to > implement p2pmem even though we'd still technically be violating the > __iomem boundary in some places. Just reacting to this mail, I still haven't had a chance to take a look at the rest of the series. The pfn_t type was invented to carry extra type and page lookup information about the memory behind a given pfn. At first glance that seems a more natural place to carry an indication that this is an "I/O" pfn. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752644AbdDCVom (ORCPT ); Mon, 3 Apr 2017 17:44:42 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:32860 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751843AbdDCVoi (ORCPT ); Mon, 3 Apr 2017 17:44:38 -0400 MIME-Version: 1.0 In-Reply-To: <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> From: Dan Williams Date: Mon, 3 Apr 2017 14:44:32 -0700 Message-ID: Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. To: Logan Gunthorpe Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers attempt to access > iomem directly through the sgl. > > I'd also probably create a p2pmem_alloc_sgl helper function so driver > writers wouldn't have to mess with sg_set_iomem_page. > > With all that in place, it should be relatively safe for drivers to > implement p2pmem even though we'd still technically be violating the > __iomem boundary in some places. Just reacting to this mail, I still haven't had a chance to take a look at the rest of the series. The pfn_t type was invented to carry extra type and page lookup information about the memory behind a given pfn. At first glance that seems a more natural place to carry an indication that this is an "I/O" pfn. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> From: Dan Williams Date: Mon, 3 Apr 2017 14:44:32 -0700 Message-ID: Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. To: Logan Gunthorpe Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers attempt to access > iomem directly through the sgl. > > I'd also probably create a p2pmem_alloc_sgl helper function so driver > writers wouldn't have to mess with sg_set_iomem_page. > > With all that in place, it should be relatively safe for drivers to > implement p2pmem even though we'd still technically be violating the > __iomem boundary in some places. Just reacting to this mail, I still haven't had a chance to take a look at the rest of the series. The pfn_t type was invented to carry extra type and page lookup information about the memory behind a given pfn. At first glance that seems a more natural place to carry an indication that this is an "I/O" pfn. From mboxrd@z Thu Jan 1 00:00:00 1970 From: dan.j.williams@intel.com (Dan Williams) Date: Mon, 3 Apr 2017 14:44:32 -0700 Subject: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. In-Reply-To: <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Message-ID: On Mon, Apr 3, 2017@2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers attempt to access > iomem directly through the sgl. > > I'd also probably create a p2pmem_alloc_sgl helper function so driver > writers wouldn't have to mess with sg_set_iomem_page. > > With all that in place, it should be relatively safe for drivers to > implement p2pmem even though we'd still technically be violating the > __iomem boundary in some places. Just reacting to this mail, I still haven't had a chance to take a look at the rest of the series. The pfn_t type was invented to carry extra type and page lookup information about the memory behind a given pfn. At first glance that seems a more natural place to carry an indication that this is an "I/O" pfn.