--- Vivek Goyal <[email protected]> wrote:
> No, as of today, kexec does not relocate vmlinux. At compilation time,
> vmlinux is compiled for a fixed address and vmlinux is loaded at that
> address. This compile address can be controlled with CONFIG_PHYSICAL_START,
> as you already mentioned in your patchset.
>
> So in the case of kdump, if one wishes to use vmlinux instead of a relocatable
> bzImage, he will re-compile the kernel for a different address and then use
> that vmlinux.
>
> OTOH, boot loader can possibly relocate vmlinux because all the relocation
> information is retained in vmlinux (Using ld option --emit-relocs). But
> probably self relocating image should be a better option as all the
> boot-loaders out there don't have to be modifed.
Well, a self relocating image cannot be an ELF file because the code
to relocate the ELF cannot be executed at the wrong place.
If relocation is needed, I would better like not to link vmlinux at a
fixed address first. In fact I wonder if we are talking of the same
kind of relocation: you seem to talk about "ld --pic-executable" while
I am thinking of "ld -r" to "locate" it at the bootloader loading time.
The main problem I see is that I do not have the code for that, and
I am going deeper/earlier into the generation of vmlinux, while comments
are "already you are too early, loading an ELF file is too complex for
a bootloader". The solution I have already is working.
> > If you cannot get a PT_LOAD
> > section, maybe we can put a simple system in NOTE, or just create a
> > PT_LOAD16 if the linker accepts other values.
>
> My guess is that PT_LOAD16 is not an acceptable value. Putting information
> in PT_NOTE seems interesting (As Eric already mentioned).
In fact, thinking more about that, I am going back to my implementation
of it, because on ia32 the interrupt vectors are at address zero and it is
obviouly an invalid address to load an ELF for this architecture.
But for the linker, it is the right address to link it (being an offset
into a non-null segment in real mode), and because the entry point has
to be zero (I cannot use the ELF entry value) the program header base
address has to be zero.
Anyway, your loader in (probably) written in C, so a test against zero
is a simple thing to do, and should be done anyway to check for an
incorrect ELF program header. I wonder if this NOTE program header is
not simply designed as an "end" marker, it does not seem to contain
anything, so me defining the realmode after that program header may
be a good idea.
> We already do checksum verification to make sure newly loaded kernel has
> not been corrupted before we jump to it. What's the point in doing the
> verification existing kernel text. Because even that is intact, and you
> reload your data section, that data section will have to be reloaded at
> the same place where previous data section was. Now after you re-loaded
> the data section, some DMA might corrupt it now (Because we never stopped
> DMAs). So loading a fresh copy of text and data section at a reserved
> memory location seems safer.
If you really are tring to catch an erroneous DMA into the kernel,
is it better to keep an exact copy of the kernel you are using somewhere
else to do a bit-to-bit comparisson after the crash, and so no relocate.
Anyway if the DMA crash has crashed the exception handling area the system
is dead anyway.
> Interesting question, How does a boot loader/user decide where to load
> the relocatable image? I think it depends on the new interesting usages
> of the relocatable kernel. As of today, kexec knows where is reserved
> memory region (Read from /proc/iomem) and it loads the image at the
> start of that reserved region (Meeting alignment restrictions, if any). So
> in this case boot loader takes the decision. May be a user option also
> can be created, something like --load-address=0xXYZ and then people
> can have fun loading same image at various addresses.
I think that you are asking too much for the bootloader user, and that
is a decision he has to take *before* the crash; even me, I would select
one address like 16 Mbytes and stick with it...
If the running Linux kernel do not erase Gujin from memory, it could
also go back to real mode and do a "longjmp()" to return to the
Gujin interface - but most of the times the system had a reason to
crash (for instance a ventilator stopped working) and you can plan
whatever you want in software...
Thanks,
Etienne.
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
