All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ahmed Samy <f.fallen45@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: linux-mm@kvack.org, zhongjiang@huawei.com
Subject: Re: ioremap_page_range: remapping of physical RAM ranges
Date: Thu, 26 Jan 2017 01:15:29 +0200	[thread overview]
Message-ID: <20170125231529.GA14993@devmasch> (raw)
In-Reply-To: <072b4406-16ef-cdf6-e968-711a60ca9a3f@nvidia.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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-01-25 23:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 19:55 ioremap_page_range: remapping of physical RAM ranges A. Samy
2017-01-25 22:27 ` John Hubbard
2017-01-25 23:15   ` Ahmed Samy [this message]
2017-01-26  8:33     ` John Hubbard
2017-01-26 18:24       ` Ahmed Samy
2017-01-28 21:11       ` Ahmed Samy
2017-01-28 21:48         ` John Hubbard
2017-01-28 21:55           ` Ahmed Samy
2017-01-28 22:12             ` Ahmed Samy
2017-01-28 22:16               ` John Hubbard
2017-01-28 22:13             ` John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170125231529.GA14993@devmasch \
    --to=f.fallen45@gmail.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=zhongjiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.