From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: John Blackwood <john.blackwood@ccur.com>, kexec@lists.infradead.org
Subject: Re: Kdump issue with percpu_alloc=lpage (Was:Re: crash_notes posted to kexec-tools)
Date: Tue, 27 Oct 2009 19:08:57 +0100 [thread overview]
Message-ID: <4AE73739.9040008@kernel.org> (raw)
In-Reply-To: <20091027142419.GB10513@redhat.com>
Hello,
Vivek Goyal wrote:
> In kdump, we allocate per cpu area using alloc_percpu() and later
> export the physical address of the area allocated to user space through
> sysfs. (/sys/devices/system/cpu/cpuN/crash_notes). kexec-tools user space
> utility makes use of this physical address to store in some ELF headers
> which in turn are used by the second kernel booted after crash.
>
> We assume that address returned by per_cpu_ptr() is unity mapped and
> use __pa() to convert that address to physical address.
>
> addr = __pa(per_cpu_ptr(crash_notes, cpunum));
>
> Is that not a valid assumption with percpu_alloc=lpage or percpu_alloc=4k
> options? If not, what's the right way to get the physical address in
> such situations?
The lpage allocator is gone in the latest tree and only "embed" and
"page" allocators are there. The only difference between the two is
that the embed one will put the first chunk inside the linearly mapped
area which in turn means that __pa() would work on static percpu
variables and some of dynamic ones but from the second chunk on and
for the page allocator, the percpu addresses will be remapped into
vmalloc area and behaves just like any other vmalloc address meaning
that the physical page can be determined using vmalloc_to_page(). So,
something like the following should work,
v = per_cpu_ptr(crash_notes, cpunum);
if (v < VMALLOC_START || v >= VMALLOC_END)
p = __pa(v);
else
p = page_to_phys(vmalloc_to_page(v));
For the now removed lpage, it would be a bit difficult and we'll
probably need to add a dedicated function to percpu to determine the
physical address. Hmmm... probably the right thing to do is to add
such function so that the user can simply call percpu_to_phys()
regardless of address?
Thanks.
--
tejun
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2009-10-27 18:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4AE5CF6F.40706@ccur.com>
2009-10-27 14:24 ` Kdump issue with percpu_alloc=lpage (Was:Re: crash_notes posted to kexec-tools) Vivek Goyal
2009-10-27 18:08 ` Tejun Heo [this message]
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=4AE73739.9040008@kernel.org \
--to=tj@kernel.org \
--cc=john.blackwood@ccur.com \
--cc=kexec@lists.infradead.org \
--cc=vgoyal@redhat.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