On 11/17/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > KERNEL_TEXT_SIZE is a kernel defined virtual address region where kernel > can reside. So x86_64 has fixed a virtual address range of 40MB for the > kernel. (Documentation/x86_64/mm.txt).
Oh, I see. I didn't know that. > Now, if you compile your kernel for 1MB physical location, it gets shifted > in vaddr range by 1MB. But it can not cross kernel defined vaddr region > and has to move somewhere between this 40MB range. That's the reason that > on x86_64 you can't comile a kernel for 64MB physical address and boot. I didn't know that either. =) I guess I've just been lucky so far... > Before my changes, we used to map first 40MB in kernel text region and > rest at linearly mapped region. But that's not a very good way of doing > things. I think we should always create a separate header for kernel. > (Same physical memory has been mapped at two virtual address regions hence > we need to create two headers to reflect that). Yes, good idea. I think this should be done both for x86_64 and ia64. > If we can determine it using /proc/kcore then it is fine otherwise we > should simply hardcode first 40MB mappeed in kernel text region. > > phdr->p_vaddr = mstart + __START_KERNEL_map; > > This will always make sure that gdb is not broken. Sounds like a plan! > > >b) we relax the elf note check in kexec-tools so that older kernels are > > > not incompatible at all and /proc/kcore is readable. What I mean is that > > > kexec-tools check for presense of a NULL being present in elf note name > > > string. Instead of returning error there, we can print a warning that > > > a null character is not present and continue processing kcore. This way > > > older kernels will not require any special processing and ELF header > > > creation logic will also be very neat. > > > > > >IMHO, we should go by the second option. What do you think? > > > > Yes, the second option sounds fine. But I see that as an enhancement > > for older kernels that can go on top of my patch. > > > > I don't think that your patch is required at all. My patch should resolve > the issue now. Your patch breaks compatibility with gdb which we don't want. You are right. > Again, I think that goals of bare metal linux and xen are very different > when it comes to kdump. So please create separate files or funcitons like > xen_prepare_64bit_elf_headers() to enforce the policies which are more > suitable for virtualized env. I guess there is a tradeoff between code duplication and maintainability. Please have a look at my patchbomb and comment if you have time. > > And until someone cooks up such an enhancement I think the best is to > > not provide a kernel PT_LOAD program header on old kernels. That > > should keep kexec-tools-testing on x86_64 on the same level as > > kexec-tools for old kernels which I think is the best way to deal with > > backwards compatibility. > > > > I have cooked up the patch now. Please try it out. Hopefully it solves > the issue for you. It does. I'm not 100% sure why, but it solves the problem. Thank you! Simon, can you please apply Viveks patch to your kexec-tools-testing tree? / magnus _______________________________________________ fastboot mailing list fastboot@lists.osdl.org https://lists.osdl.org/mailman/listinfo/fastboot
