[PATCH 1/2] kexec: add phys_offset field

[Mika Westerberg]

I'm not subscribed to the list so please CC me. I had to dig this message from
the archives.

On Mon, Apr 26, 2010 at 02:32:21PM -0400, Dave Anderson wrote:
> 
> ----- kexec-request at lists.infradead.org wrote:
> 
> > 
> > Message: 1
> > Date: Mon, 26 Apr 2010 12:03:30 +0300
> > From: Mika Westerberg <ext-mika.1.westerberg at nokia.com>
> > To: kexec at lists.infradead.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Subject: [PATCH 1/2] kexec: add phys_offset field
> > Message-ID:
> > 
> > <e376969c3d29696ce11488af59605ada56fdccff.1272271391.git.ext-mika.1.westerberg at nokia.com>
> > 	
> > 
> > Add new field 'phys_offset' to struct elf_info. This field is used to calculate
> > virtual address of PT_LOAD segment on architectures where physical memory
> > doesn't always start at address 0 (namely ARM).
> > 
> > Signed-off-by: Mika Westerberg <ext-mika.1.westerberg at nokia.com>
> > ---
> >  kexec/crashdump-elf.c |    9 ++++++++-
> >  kexec/crashdump.h     |    1 +
> >  2 files changed, 9 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> > index 6bcef8d..1291174 100644
> > --- a/kexec/crashdump-elf.c
> > +++ b/kexec/crashdump-elf.c
> > @@ -236,7 +236,14 @@ int FUNC(struct kexec_info *info,
> >  		 * memory region.
> >  		 */
> >  		phdr->p_paddr = mstart;
> > -		phdr->p_vaddr = mstart + elf_info->page_offset;
> > +		/*
> > +		 * In some architectures (namely ARM), physical memory doesn't
> > +		 * always start at 0 so we need to calculate virtual address
> > +		 * based on elf_info->phys_offset like:
> > +		 *     virt = phys + page_offset - phys_offset
> > +		 */
> > +		phdr->p_vaddr = mstart + elf_info->page_offset -
> > +				elf_info->phys_offset;
> >  		phdr->p_filesz	= phdr->p_memsz	= mend - mstart + 1;
> >  		/* Do we need any alignment of segments? */
> >  		phdr->p_align	= 0;
> > diff --git a/kexec/crashdump.h b/kexec/crashdump.h
> > index 30d6f29..8c0ccda 100644
> > --- a/kexec/crashdump.h
> > +++ b/kexec/crashdump.h
> > @@ -27,6 +27,7 @@ struct crash_elf_info {
> >  	unsigned long backup_src_end;
> >  
> >  	unsigned long long page_offset;
> > +	unsigned long long phys_offset;
> >  	unsigned long lowmem_limit;
> >  
> >  	int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> > -- 
> 
> Can you can possibly leave the p_vaddr field as-is on the other
> non-ARM architectures?

Sure. I assumed that all architectures declare struct crash_elf_info as static
data but x86_64 seems to allocate it from the stack.

If we change x86_64 part not to allocate it from the stack then this should
have no effect on architectures that don't specify elf_info->phys_offset. Does
that sound reasonable?

> The p_vaddr field in the ELF header has always been presumed
> to be a kernel unity-mapped virtual address.  As I understand
> it, this will create a "hybrid" virtual address that is no longer
> aligned with the kernel's concept of a unity-mapped address.

Idea here was to make sure that virtual addresses in PT_LOAD segments are
calculated correctly based on PHYS_OFFSET field. For example with OMAP3,
physical memory starts at 0x80000000 so for 0xc0000000 (PAGE_OFFSET) we get:

	phdr->p_vaddr = 0x80000000 + 0xc0000000 = 0x40000000

which is not correct. But taking PHYS_OFFSET into equation we get

	phdr->p_vaddr = 0x80000000 + 0xc0000000 - 0x80000000 = 0xc0000000

which is correct.

> The crash utility for other architectures calculates the phys_offset,
> or has the phys_base passed in the makedumpfile header.

OK. I'll have to check these. I had the impression that vmcore file could be
used also as-is without any post-processing.

Thanks,
MW