From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f199.google.com (mail-ot0-f199.google.com [74.125.82.199]) by kanga.kvack.org (Postfix) with ESMTP id 6BDBF6B0033 for ; Wed, 25 Jan 2017 14:55:26 -0500 (EST) Received: by mail-ot0-f199.google.com with SMTP id j49so163058827otb.7 for ; Wed, 25 Jan 2017 11:55:26 -0800 (PST) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com. [2607:f8b0:4003:c0f::243]) by mx.google.com with ESMTPS id j11si9380291oib.203.2017.01.25.11.55.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:55:25 -0800 (PST) Received: by mail-ot0-x243.google.com with SMTP id 65so24807824otq.2 for ; Wed, 25 Jan 2017 11:55:25 -0800 (PST) MIME-Version: 1.0 From: "A. Samy" Date: Wed, 25 Jan 2017 21:55:25 +0200 Message-ID: Subject: ioremap_page_range: remapping of physical RAM ranges Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: zhongjiang@huawei.com Hi, Commit 3277953de2f31 un-exported ioremap_page_range(), what is an alternative method of remapping a physical ram range... This function was very useful, examples here: https://github.com/asamy/ksm/blob/master/mm.c#L38 and here: https://github.com/asamy/ksm/blob/master/ksm.c#L410 etc... So, you're forcing me to either reimplement it on my own (which is merely copy-pasting the kernel function), unless you have a suggestion on what else to use (which I could never find other)? Thanks, -- asamy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199]) by kanga.kvack.org (Postfix) with ESMTP id 22D3C6B0033 for ; Wed, 25 Jan 2017 17:31:07 -0500 (EST) Received: by mail-pf0-f199.google.com with SMTP id 201so286640935pfw.5 for ; Wed, 25 Jan 2017 14:31:07 -0800 (PST) Received: from hqemgate16.nvidia.com (hqemgate16.nvidia.com. [216.228.121.65]) by mx.google.com with ESMTPS id h2si24723233pgc.40.2017.01.25.14.31.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 14:31:06 -0800 (PST) Subject: Re: ioremap_page_range: remapping of physical RAM ranges References: From: John Hubbard Message-ID: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> Date: Wed, 25 Jan 2017 14:27:27 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "A. Samy" , linux-mm@kvack.org Cc: zhongjiang@huawei.com On 01/25/2017 11:55 AM, A. Samy wrote: > Hi, > > Commit 3277953de2f31 un-exported ioremap_page_range(), what is an > alternative method of remapping a physical ram range... This function > was very useful, examples here: > https://github.com/asamy/ksm/blob/master/mm.c#L38 and here: > https://github.com/asamy/ksm/blob/master/ksm.c#L410 etc... > > So, you're forcing me to either reimplement it on my own (which is > merely copy-pasting the kernel function), unless you have a suggestion > on what else to use (which I could never find other)? Hi A. Samy, I'm sorry this caught you by surprise, let's try get your use case covered. My thinking on this was: the exported ioremap* family of functions was clearly intended to provide just what the name says: mapping of IO (non-RAM) memory. If normal RAM is to be re-mapped, then it should not be done "casually" in a driver, as a (possibly unintended) side effect of a function that implies otherwise. Either it should be done within the core mm code, or perhaps a new, better-named wrapper could be provided, for cases such as yours. After a very quick peek at your github code, it seems that your mm_remap() routine already has some code in common with __ioremap_caller(), so I'm thinking that we could basically promote your mm_remap to the in-tree kernel and EXPORT it, and maybe factor out the common parts (or not--it's small, after all). Thoughts? If you like it, I'll put something together here. thanks john h > > Thanks, > > -- > asamy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 9AE866B0033 for ; Wed, 25 Jan 2017 18:15:34 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id r126so41208253wmr.2 for ; Wed, 25 Jan 2017 15:15:34 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com. [2a00:1450:400c:c09::244]) by mx.google.com with ESMTPS id g11si24201688wmi.59.2017.01.25.15.15.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 15:15:33 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id d140so46288093wmd.2 for ; Wed, 25 Jan 2017 15:15:33 -0800 (PST) Date: Thu, 26 Jan 2017 01:15:29 +0200 From: Ahmed Samy Subject: Re: ioremap_page_range: remapping of physical RAM ranges Message-ID: <20170125231529.GA14993@devmasch> References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: linux-mm@kvack.org, zhongjiang@huawei.com On Wed, Jan 25, 2017 at 02:27:27PM -0800, John Hubbard wrote: > > Hi A. Samy, > > I'm sorry this caught you by surprise, let's try get your use case covered. > > My thinking on this was: the exported ioremap* family of functions was > clearly intended to provide just what the name says: mapping of IO (non-RAM) > memory. If normal RAM is to be re-mapped, then it should not be done > "casually" in a driver, as a (possibly unintended) side effect of a function > that implies otherwise. Either it should be done within the core mm code, or > perhaps a new, better-named wrapper could be provided, for cases such as > yours. Hi John, I agree. I assume whoever exported it was also doing it for the same purpose as mine[?] > > After a very quick peek at your github code, it seems that your mm_remap() > routine already has some code in common with __ioremap_caller(), so I'm > thinking that we could basically promote your mm_remap to the in-tree kernel > and EXPORT it, and maybe factor out the common parts (or not--it's small, > after all). Thoughts? If you like it, I'll put something together here. That'd be a good solution, it's actually sometimes useful to remap physical ram in general, specifically for memory imaging tools, etc. How about also exporting walk_system_ram_range()? It seems to be defined conditionally, so I am not sure if that would be a good idea. [ See also mm_cache_ram_ranges() in mm.c in github a?? it's also a hacky way to get RAM ranges. ] How about something like: /* vm_flags incase locking is required, in my case, I need it for VMX * root where there is no interrupts. */ void *remap_ram_range(unsigned long phys, unsigned long size, unsigned long vm_flags) { struct vm_struct *area; unsigned long psize; unsigned long vaddr; psize = (size >> PAGE_SHIFT) + (size & (PAGE_SIZE - 1)) != 0; area = get_vm_area_caller(size, VM_IOREMAP | vm_flags, __builtin_return_address(0)); if (!area) return NULL; area->phys_addr = phys & ~(PAGE_SIZE - 1); vaddr = (unsigned long)area->addr; if (remap_page_range(vaddr, vaddr + size, phys, size)) goto err_remap; return (void *)vaddr + phys & (PAGE_SIZE - 1); err_remap: free_vm_area(area); return NULL; } Of course you can add protection, etc. > > thanks > john h > Thanks, asamy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 61E3A6B0253 for ; Thu, 26 Jan 2017 03:33:05 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id z67so302599228pgb.0 for ; Thu, 26 Jan 2017 00:33:05 -0800 (PST) Received: from hqemgate15.nvidia.com (hqemgate15.nvidia.com. [216.228.121.64]) by mx.google.com with ESMTPS id 3si797570plx.91.2017.01.26.00.33.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 00:33:04 -0800 (PST) Subject: Re: ioremap_page_range: remapping of physical RAM ranges References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> From: John Hubbard Message-ID: <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> Date: Thu, 26 Jan 2017 00:33:02 -0800 MIME-Version: 1.0 In-Reply-To: <20170125231529.GA14993@devmasch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Ahmed Samy Cc: linux-mm@kvack.org, zhongjiang@huawei.com On 01/25/2017 03:15 PM, Ahmed Samy wrote: > On Wed, Jan 25, 2017 at 02:27:27PM -0800, John Hubbard wrote: >> >> Hi A. Samy, >> >> I'm sorry this caught you by surprise, let's try get your use case cover= ed. >> >> My thinking on this was: the exported ioremap* family of functions was >> clearly intended to provide just what the name says: mapping of IO (non-= RAM) >> memory. If normal RAM is to be re-mapped, then it should not be done >> "casually" in a driver, as a (possibly unintended) side effect of a func= tion >> that implies otherwise. Either it should be done within the core mm code= , or >> perhaps a new, better-named wrapper could be provided, for cases such as >> yours. > Hi John, > > I agree. I assume whoever exported it was also doing it for the same > purpose as mine[?] >> >> After a very quick peek at your github code, it seems that your mm_remap= () >> routine already has some code in common with __ioremap_caller(), so I'm >> thinking that we could basically promote your mm_remap to the in-tree ke= rnel >> and EXPORT it, and maybe factor out the common parts (or not--it's small= , >> after all). Thoughts? If you like it, I'll put something together here. > That'd be a good solution, it's actually sometimes useful to remap physic= al > ram in general, specifically for memory imaging tools, etc. > > How about also exporting walk_system_ram_range()? It seems to be defined > conditionally, so I am not sure if that would be a good idea. That routine has an interesting history. At first glance, I think it used t= o be=20 exported. And now it is not. And it's ifdef'd out only for powerpc. I'll lo= ok into=20 the history and intentions of that some more... > [ See also mm_cache_ram_ranges() in mm.c in github =E2=80=93 it's also a= hacky > way to get RAM ranges. ] Yes, I see. > > How about something like: > > /* vm_flags incase locking is required, in my case, I need it for VMX > * root where there is no interrupts. */ > void *remap_ram_range(unsigned long phys, unsigned long size, > unsigned long vm_flags) > { > struct vm_struct *area; > unsigned long psize; > unsigned long vaddr; > > psize =3D (size >> PAGE_SHIFT) + (size & (PAGE_SIZE - 1)) !=3D 0; > area =3D get_vm_area_caller(size, VM_IOREMAP | vm_flags, > __builtin_return_address(0)); > if (!area) > return NULL; > > area->phys_addr =3D phys & ~(PAGE_SIZE - 1); > vaddr =3D (unsigned long)area->addr; > if (remap_page_range(vaddr, vaddr + size, phys, size)) That's ioremap_page_range, I assume (rather than remap_page_range)? Overall, the remap_ram_range approach looks reasonable to me so far. I'll l= ook into=20 the details tomorrow. I'm sure that most people on this list already know this, but...could you s= ay a few=20 more words about how remapping system ram is used, why it's a good thing an= d not a=20 bad thing? :) thanks john h > goto err_remap; > > return (void *)vaddr + phys & (PAGE_SIZE - 1); > err_remap: > free_vm_area(area); > return NULL; > } > > Of course you can add protection, etc. >> >> thanks >> john h >> > Thanks, > asamy > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id E7B876B0033 for ; Thu, 26 Jan 2017 13:24:13 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id jz4so41549350wjb.5 for ; Thu, 26 Jan 2017 10:24:13 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com. [2a00:1450:400c:c09::244]) by mx.google.com with ESMTPS id 36si2954896wrp.148.2017.01.26.10.24.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:24:12 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id d140so52405419wmd.2 for ; Thu, 26 Jan 2017 10:24:12 -0800 (PST) Date: Thu, 26 Jan 2017 20:24:08 +0200 From: Ahmed Samy Subject: Re: ioremap_page_range: remapping of physical RAM ranges Message-ID: <20170126182408.GA60252@devmasch> References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: linux-mm@kvack.org, zhongjiang@huawei.com On Thu, Jan 26, 2017 at 12:33:02AM -0800, John Hubbard wrote: > > That's ioremap_page_range, I assume (rather than remap_page_range)? Yes, I renamed it for your convience. > > Overall, the remap_ram_range approach looks reasonable to me so far. I'll > look into the details tomorrow. > > I'm sure that most people on this list already know this, but...could you > say a few more words about how remapping system ram is used, why it's a good > thing and not a bad thing? :) > It's useful for memory imaging tools, where you'd iterate through available ram ranges, and dump it. You could look at Google's Rekall, I am not sure if they take the exact same approach. Another use is mine, when I use EPT (GPA <-> HPA), let's say when I want to write to a guest virtual address, then I first need to translate that into GPA, then translate to HPA through EPT, and remap HPA to get a safe HVA, then I can write it to safely. You can see a few use cases in the github link... You could assume the same for userspace to kernel space mapping, you mostly wouldn't trust the user address passed, so you'd remap it to kernel space first (ptrace, whatever...). asamy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id CFBC56B0038 for ; Sat, 28 Jan 2017 16:11:24 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id gt1so53224846wjc.0 for ; Sat, 28 Jan 2017 13:11:24 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com. [2a00:1450:400c:c09::241]) by mx.google.com with ESMTPS id k29si7605902wmh.124.2017.01.28.13.11.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 13:11:23 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id r126so67210408wmr.3 for ; Sat, 28 Jan 2017 13:11:23 -0800 (PST) Date: Sat, 28 Jan 2017 23:11:19 +0200 From: Ahmed Samy Subject: Re: ioremap_page_range: remapping of physical RAM ranges Message-ID: <20170128211119.GA68646@devmasch> References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: linux-mm@kvack.org, zhongjiang@huawei.com On Thu, Jan 26, 2017 at 12:33:02AM -0800, John Hubbard wrote: > > That's ioremap_page_range, I assume (rather than remap_page_range)? > > Overall, the remap_ram_range approach looks reasonable to me so far. I'll > look into the details tomorrow. > > I'm sure that most people on this list already know this, but...could you > say a few more words about how remapping system ram is used, why it's a good > thing and not a bad thing? :) > > thanks > john h > Please let me know if you're going to actually make a commit that either 1) reverts that commit 2) implements a "separate" function... Either way, I don't think the un-export is reasonable in the slightest, if that function is too low-level, then why not also un-export pmd_offset(), pgd_offset(), perhaps current task too? These interact directly with low-level stuff, not meant for drivers, the function is meant to be low-level, I don't know what made you think that people use it wrong? How about writing proper documentation about it instead? Besides, even if that function does not exist, you can always iterate the PTEs and set the physical address, it is not hard, but the safe way is via the kernel knowledge, which is what that function when combined with others (from vmalloc) provide... How about this, a function as part of vmalloc, that says something like `void *vremap(unsigned long phys, unsigned long size, unsigned long flags);`? Then that solved the problem and there is no need for "low level" functions, anymore. Other than, if you're not going to apply a proper workaround, then let me know, and I'll handle it myself from here. I don't want this to get past the next -rc release, so please let's get this fixed... Thanks, asamy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 428936B0253 for ; Sat, 28 Jan 2017 16:48:54 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id e4so269997666pfg.4 for ; Sat, 28 Jan 2017 13:48:54 -0800 (PST) Received: from hqemgate14.nvidia.com (hqemgate14.nvidia.com. [216.228.121.143]) by mx.google.com with ESMTPS id u123si4947104pgc.280.2017.01.28.13.48.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 13:48:53 -0800 (PST) Subject: Re: ioremap_page_range: remapping of physical RAM ranges References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> <20170128211119.GA68646@devmasch> From: John Hubbard Message-ID: <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> Date: Sat, 28 Jan 2017 13:48:46 -0800 MIME-Version: 1.0 In-Reply-To: <20170128211119.GA68646@devmasch> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ahmed Samy Cc: linux-mm@kvack.org, zhongjiang@huawei.com On 01/28/2017 01:11 PM, Ahmed Samy wrote: > On Thu, Jan 26, 2017 at 12:33:02AM -0800, John Hubbard wrote: >> >> That's ioremap_page_range, I assume (rather than remap_page_range)? >> >> Overall, the remap_ram_range approach looks reasonable to me so far. I'll >> look into the details tomorrow. >> >> I'm sure that most people on this list already know this, but...could you >> say a few more words about how remapping system ram is used, why it's a good >> thing and not a bad thing? :) >> >> thanks >> john h >> > Please let me know if you're going to actually make a commit that either > 1) reverts that commit > 2) implements a "separate" function... This email caught me as I was just sitting down to this. A couple days later than I expected, sorry. > > Either way, I don't think the un-export is reasonable in the slightest, if that > function is too low-level, then why not also un-export pmd_offset(), > pgd_offset(), perhaps current task too? These interact directly with low-level > stuff, not meant for drivers, the function is meant to be low-level, I don't know > what made you think that people use it wrong? How about writing proper > documentation about it instead? heh, I'm sure we're in strong agreement there: good documentation is desirable, yet sometimes missing. :) As for "what made you think that people use it wrong?", I think Zhong spotted a potential problem, then (if I understand correctly) decided that it was actually OK, but by then, I had egged him on to remove the EXPORT, because it looked "off" to me, too. (It still does.) So I'll take the heat for this one, and that's why I'm following up on it. Besides, even if that function does not exist, > you can always iterate the PTEs and set the physical address, it is not hard, > but the safe way is via the kernel knowledge, which is what that function > when combined with others (from vmalloc) provide... > > How about this, a function as part of vmalloc, that says something like > `void *vremap(unsigned long phys, unsigned long size, unsigned long flags);`? > Then that solved the problem and there is no need for "low level" functions, > anymore. Quick question, what do you mean "a function as part of vmalloc"? > > Other than, if you're not going to apply a proper workaround, then let me know, > and I'll handle it myself from here. I don't want this to get past the next > -rc release, so please let's get this fixed... Agreed. thanks, john h > > Thanks, > asamy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 068096B0260 for ; Sat, 28 Jan 2017 16:55:10 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id r126so60316233wmr.2 for ; Sat, 28 Jan 2017 13:55:09 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com. [2a00:1450:400c:c09::242]) by mx.google.com with ESMTPS id h19si10816220wrc.243.2017.01.28.13.55.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 13:55:08 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id c85so67256126wmi.1 for ; Sat, 28 Jan 2017 13:55:08 -0800 (PST) Date: Sat, 28 Jan 2017 23:55:05 +0200 From: Ahmed Samy Subject: Re: ioremap_page_range: remapping of physical RAM ranges Message-ID: <20170128215504.GA69125@devmasch> References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> <20170128211119.GA68646@devmasch> <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: linux-mm@kvack.org, zhongjiang@huawei.com On Sat, Jan 28, 2017 at 01:48:46PM -0800, John Hubbard wrote: > Quick question, what do you mean "a function as part of vmalloc"? Take a look at `vmap()', it should be like that API. Dunno if vmap can be used in place, haven't tried, maybe can get `struct page` and then use vmap? I don't know, what do you think? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id C49B96B0266 for ; Sat, 28 Jan 2017 17:12:40 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id x4so32028wme.3 for ; Sat, 28 Jan 2017 14:12:40 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com. [2a00:1450:400c:c09::244]) by mx.google.com with ESMTPS id p187si7735082wmp.96.2017.01.28.14.12.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 14:12:39 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id r126so67477543wmr.3 for ; Sat, 28 Jan 2017 14:12:39 -0800 (PST) Date: Sun, 29 Jan 2017 00:12:35 +0200 From: Ahmed Samy Subject: Re: ioremap_page_range: remapping of physical RAM ranges Message-ID: <20170128221235.GA69602@devmasch> References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> <20170128211119.GA68646@devmasch> <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> <20170128215504.GA69125@devmasch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170128215504.GA69125@devmasch> Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: linux-mm@kvack.org, zhongjiang@huawei.com On Sat, Jan 28, 2017 at 11:55:05PM +0200, Ahmed Samy wrote: > Take a look at `vmap()', it should be like that API. Dunno if vmap can be used > in place, haven't tried, maybe can get `struct page` and then use vmap? I > don't know, what do you think? OK, so, I just tried vmap() with a struct page retrieved by pfn_to_page() which seems to work just fine, so I suppose this can be disregarded, it's my fault; I should've done more research before posting this to the list. Sorry. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199]) by kanga.kvack.org (Postfix) with ESMTP id C208E6B026A for ; Sat, 28 Jan 2017 17:13:16 -0500 (EST) Received: by mail-pf0-f199.google.com with SMTP id f144so401474735pfa.3 for ; Sat, 28 Jan 2017 14:13:16 -0800 (PST) Received: from hqemgate15.nvidia.com (hqemgate15.nvidia.com. [216.228.121.64]) by mx.google.com with ESMTPS id z87si8250575pfi.113.2017.01.28.14.13.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 14:13:15 -0800 (PST) Subject: Re: ioremap_page_range: remapping of physical RAM ranges References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> <20170128211119.GA68646@devmasch> <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> <20170128215504.GA69125@devmasch> From: John Hubbard Message-ID: Date: Sat, 28 Jan 2017 14:13:10 -0800 MIME-Version: 1.0 In-Reply-To: <20170128215504.GA69125@devmasch> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ahmed Samy Cc: linux-mm@kvack.org, zhongjiang@huawei.com On 01/28/2017 01:55 PM, Ahmed Samy wrote: > On Sat, Jan 28, 2017 at 01:48:46PM -0800, John Hubbard wrote: >> Quick question, what do you mean "a function as part of vmalloc"? > Take a look at `vmap()', it should be like that API. Dunno if vmap can be used > in place, haven't tried, maybe can get `struct page` and then use vmap? I > don't know, what do you think? Right, vmap is probably what you're looking for here. The way this story usually goes in my experience is: if you're actually dealing with real RAM, you are also dealing in struct pages. So you lookup the struct pages, keep track of them, (maybe also pin them with get_user_pages), and then map them with vmap. Beyond the out-of-tree driver that I'm supporting (which uses vmap in that way), there are also a *lot* of in-tree examples that also do it. Are you buying this? :) thanks john h > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id AEA506B026C for ; Sat, 28 Jan 2017 17:16:47 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id 3so148462804pgj.6 for ; Sat, 28 Jan 2017 14:16:47 -0800 (PST) Received: from hqemgate14.nvidia.com (hqemgate14.nvidia.com. [216.228.121.143]) by mx.google.com with ESMTPS id n3si8220371pfg.293.2017.01.28.14.16.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 14:16:46 -0800 (PST) Subject: Re: ioremap_page_range: remapping of physical RAM ranges References: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.com> <20170125231529.GA14993@devmasch> <47fe454a-249d-967b-408f-83c5046615e4@nvidia.com> <20170128211119.GA68646@devmasch> <9779dfc7-5af6-666a-2cca-08f7ddd30e34@nvidia.com> <20170128215504.GA69125@devmasch> <20170128221235.GA69602@devmasch> From: John Hubbard Message-ID: <034a3124-10a0-13ad-cbe8-19864c01b2a5@nvidia.com> Date: Sat, 28 Jan 2017 14:16:45 -0800 MIME-Version: 1.0 In-Reply-To: <20170128221235.GA69602@devmasch> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ahmed Samy Cc: linux-mm@kvack.org, zhongjiang@huawei.com On 01/28/2017 02:12 PM, Ahmed Samy wrote: > On Sat, Jan 28, 2017 at 11:55:05PM +0200, Ahmed Samy wrote: >> Take a look at `vmap()', it should be like that API. Dunno if vmap can be used >> in place, haven't tried, maybe can get `struct page` and then use vmap? I >> don't know, what do you think? > OK, so, I just tried vmap() with a struct page retrieved by pfn_to_page() which > seems to work just fine, so I suppose this can be disregarded, it's my fault; I > should've done more research before posting this to the list. > > Sorry. No problem at all, delighted to hear that your code will be OK! thanks john h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org