[PATCH 1/2] kexec: add phys_offset field

[Dave Anderson]

----- "Mika Westerberg" <ext-mika.1.westerberg at nokia.com> wrote:

> On Tue, Apr 27, 2010 at 03:08:54PM +0200, ext Dave Anderson wrote:
> > ----- "Mika Westerberg" <ext-mika.1.westerberg at nokia.com> wrote:
> > > 
> > > 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.
> > 
> > Yes, I understand completely -- we've been there...  ;-)
> > 
> > The issue is that there would be a disconnect between the actual kernel
> > virtual addresses used in the vmlinux file vs. your "calculated" virtual
> > addresses in the header, and to me that goes against the grain of what
> > the p_vaddr field is supposed to mean. 
> > 
> > The ELF spec defines them:
> > 
> >   p_vaddr  This member gives the virtual address at which the first
> >            byte of the segment resides in memory.
> > 
> >   p_paddr  On systems for which physical addressing is relevant, this
> >            member is reserved for the segment's physical address.
> >            Because System V ignores physical addressing for application
> >            programs, this member has unspecified contents for executable
> >            files and shared objects.
> > 
> > To me, the term "virtual address" means the virtual addresses used by the
> > executable.  Your scheme "calculates" a p_vaddr based upon the p_paddr.
> 
> Sorry, I have to ask some clarifications to understand this.
> 
> If the kernel image is linked at virtual address 0xc0008000 which is the case
> with ARM kernel for example. Then how following is legitimate kernel virtual
> address?
> 
> 	phdr->p_vaddr = mstart + elf_info->page_offset;
> 
> if the first physical memory region starts for example at 0x80000000, and
> PAGE_OFFSET is 0xc0000000 we get:
> 
> 	phdr->p_vaddr = 0x80000000 + 0xc0000000
> 
> this results virtual address 0x40000000 (in 32-bit) for the kernel direct mapped
> region, which I think is not the same as used by the executable (the vmlinux
> file):
> 
> % objdump -h vmlinux
> 
> vmlinux:     file format elf32-little
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .note.gnu.build-id 00000024  00000000  00000000  00008000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   1 .init         0001f6ed  c0008000  c0008000  00010000  2**5
>                   CONTENTS, ALLOC, LOAD, CODE
>   2 .text         0031706a  c0028000  c0028000  00030000  2**6
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> ...
> 
> Am I missing something?

I may be missing something w/respect to 32-bit x86, but AIUI, the
unity-mapped region can only map the first 1GB of physical memory,
starting at physical address 0.  So you couldn't do what you suggest,
i.e., where the resultant unity-mapped address wraps around into
the user-space region.

But for x86, their is no concept of a mapped kernel region in addition
to the unity-mapped region(s), as there is with x86_64 and ia64.  It's
presumed that the primary kernel is based at physical adress 0, so when
the PAGE_OFFSET is stripped off, you have the physical address.

Dave