Re: Kdump issue with percpu_alloc=lpage

[Vivek Goyal <vgoyal@redhat.com>]

On Tue, Oct 27, 2009 at 02:16:21PM -0500, John Blackwood wrote:
>
> > 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?
>
> Hi Tejun,
>
> Just my 2 cent's worth...
>
> I like the idea of having a percpu_to_phys() function that others can
> call so that such detail are localized... and this also would tend to
> be maintained better over time, since it would be more visible being
> located near where the percpu support is implmented.
>
> Thank you for the information.

Thanks Tejun. percpu_to_phys() makes sense to me also. John, would you like to
post a patch for this.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec