On Wed, Feb 14, 2007 at 05:57:58PM +0800, Zou, Nanhai wrote: > > -----Original Message----- > > From: Magnus Damm [mailto:[EMAIL PROTECTED] > > Sent: 2007年2月14日 16:28 > > To: [EMAIL PROTECTED] > > Cc: Horms; Zou, Nanhai; [email protected]; [email protected] > > Subject: Re: Zero size /proc/vmcore on ia64 > > > > Vivek, everyone, > > > > On 2/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote: > > > I think we should not remove this check because even to parse the info > > > passed in ELF headers, you need to first read the ELF headers from crashed > > > kernel's memory. So if some programming error has passed wrong location of > > > ELF headers (elfcoreheader= invalid location) then we might try reading > > > the > > > elf header from a non-existing physical page frame. > > > > Are you saying that the ELF header is located in the memory space of > > the first kernel? > > > > The way I read the code the ELF header is put into the reserved memory > > space for the secondary kernel. At least on ia64 that is true, and I > > think the same goes for i386. > > > > And the fact that the ELF header is put in to the secondary kernel > > brings me memory setup problems on ia64. > > > > Basically the ELF header is marked as EFI_UNUSABLE_MEMORY by the EFI > > mangling code in purgatory. The secondary kernel detects this while > > parsing the EFI tables and refuses to use/map the other memory present > > in the same 16M granule. And in my case the initramfs happens to be > > located in the same granule... boom! No good. =) > > > > So I'm wondering about the reason why we put the ELF header in the > > secondary kernel. Can't we just put it in the first kernel and be done > > with it? We still point it out using the kernel command line, don't > > we? > > My first design is that putting data in second kernel is easy and > safer. We could put it in the first kernel if we provide an interface > to reserve this area at the time of kexec -p so that nobody will touch > it even at the time of crash. > > Align that buffer to 16M will solve the issue but that seems to be a > waste of the useful memory? Another way is append this elf header to > command line in purgatory, like we append the ummy efi function, maybe > this is too hacky?
I think that the dummy efi function is already way to hacky. I'd like to work out a (good) way to get rid of it. For starters the PAGE_OFFSET is hardcoded at kexec-tools compile time - which breaks xen as it has a different PAGE_OFFSET. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
