[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130703095913.6f6d145d@holzheu>
Date: Wed, 3 Jul 2013 09:59:13 +0200
From: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
Jan Willeke <willeke@...ibm.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org
Subject: Re: [PATCH v6 2/5] s390/vmcore: Use ELF header in new memory
feature
On Tue, 2 Jul 2013 12:23:23 -0400
Vivek Goyal <vgoyal@...hat.com> wrote:
> On Mon, Jul 01, 2013 at 09:32:36PM +0200, Michael Holzheu wrote:
>
> [..]
> > +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
> > +{
> > + void *src = (void *)(unsigned long)*ppos;
> > +
> > + src = elfcorehdr_newmem ? src : src - OLDMEM_BASE;
>
> Seriously, we need to get rid of all this OLDMEM_BASE logic in s390
> specific code. For regular kdump, it is no different than x86. Only
> special handling required for zfcpdump for HSA region.
>
> Why do we need above. Is it to cover the case where elfcorehdr have
> been prepared by user space? Are elf headers initially stored in
> reserved region and then swapped. Why do we need to swap these or
> why kexec-tools could not take care of swapping it.
I know it is confusing. The "src - OLDMEM_BASE" term is currently
needed because of the swap issue that we have discussed already. We
load the ELF header into reserved memory
[OLDMEM_BASE, OLDMEM_BASE + OLDMEM_SIZE] that is swapped with
[0, OLDMEM_SIZE]. So the ELF header address has to be adjusted.
Thanks!
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists