Zero size /proc/vmcore on ia64

[horms at verge.net.au (Horms)]

On Wed, Feb 14, 2007 at 05:57:58PM +0800, Zou, Nanhai wrote:
> > -----Original Message-----
> > From: Magnus Damm [mailto:magnus.damm at gmail.com]
> > Sent: 2007?2?14? 16:28
> > To: vgoyal at in.ibm.com
> > Cc: Horms; Zou, Nanhai; fastboot at lists.osdl.org; linux-ia64 at vger.kernel.org
> > Subject: Re: Zero size /proc/vmcore on ia64
> > 
> > Vivek, everyone,
> > 
> > On 2/8/07, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> > > I think we should not remove this check because even to parse the info
> > > passed in ELF headers, you need to first read the ELF headers from crashed
> > > kernel's memory. So if some programming error has passed wrong location of
> > > ELF headers (elfcoreheader= invalid location) then we might try reading the
> > > elf header from a non-existing physical page frame.
> > 
> > Are you saying that the ELF header is located in the memory space of
> > the first kernel?
> > 
> > The way I read the code the ELF header is put into the reserved memory
> > space for the secondary kernel. At least on ia64 that is true, and I
> > think the same goes for i386.
> > 
> > And the fact that the ELF header is put in to the secondary kernel
> > brings me memory setup problems on ia64.
> > 
> > Basically the ELF header is marked as EFI_UNUSABLE_MEMORY by the EFI
> > mangling code in purgatory. The secondary kernel detects this while
> > parsing the EFI tables and refuses to use/map the other memory present
> > in the same 16M granule. And in my case the initramfs happens to be
> > located in the same granule... boom! No good. =)
> > 
> > So I'm wondering about the reason why we put the ELF header in the
> > secondary kernel. Can't we just put it in the first kernel and be done
> > with it? We still point it out using the kernel command line, don't
> > we?
> 
>   My first design is that putting data in second kernel is easy and
> safer. We could put it in the first kernel if we provide an interface
> to reserve this area at the time of kexec -p so that nobody will touch
> it even at the time of crash.
> 
>   Align that buffer to 16M will solve the issue but that seems to be a
> waste of the useful memory?  Another way is append this elf header to
> command line in purgatory, like we append the ummy efi function, maybe
> this is too hacky?

I think that the dummy efi function is already way to hacky.
I'd like to work out a (good) way to get rid of it.
For starters the PAGE_OFFSET is hardcoded at kexec-tools compile time -
which breaks xen as it has a different PAGE_OFFSET.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/