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 20:24:08 +0200 [thread overview]
Message-ID: <20170126182408.GA60252@devmasch> (raw)
In-Reply-To: <47fe454a-249d-967b-408f-83c5046615e4@nvidia.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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-01-26 18:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 19:55 A. Samy
2017-01-25 22:27 ` John Hubbard
2017-01-25 23:15 ` Ahmed Samy
2017-01-26 8:33 ` John Hubbard
2017-01-26 18:24 ` Ahmed Samy [this message]
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=20170126182408.GA60252@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox