On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > Well, trying to put the already discussed ideas together. I was > > planning to work on following design. Please comment. > > > > Crashed Kernel <-->Capture Kernel(or User Space) Interface: > > ---------------------------------------------------------- > > > > The whole idea is that Crash image is represented in ELF Core format. > > These ELF Headers are prepared by kexec-tools user space and put in one > > segment. Address of start of image is passed to the capture kernel(or > > user space) using one command line (eg. crashimage=). Now either kernel > > space or user space can parse the elf headers and extract required > > information and export final kernel elf core image. > > Sounds sane. We need to make certain there is a checksum of that > region but putting it in a separate segment should ensure that. > > I also think we need to look at the name crashimage= and see if we > can find something more descriptive. But that is minor. Possibly > elfcorehdr= We have a little while to think about that one before we > are stuck.
"elfcorehdr=" also looks good. > > > > [EMAIL PROTECTED] wrote: > > > If we were using an ELF header I would include one PT_NOTE program > > > header per cpu (Giving each cpu it's own area to mess around in). > > > And I would use one PT_LOAD segment per possible memory zone. > > > So in the worst case (current sgi altix) (MAX_NUMNODES=256, > > > MAX_NR_ZONES=3, MAX_NR_CPUS=1024) 256*3+1024 = 1792 program > > > headers. At 56 bytes per 64bit program header that is 100352 bytes > > > or 98KiB. A little bit expensive. A tuned data structure with > > > 64bit base and size would only consume 1792*16 = 28672 or 28KiB. > > > > If I prepare One elf header for each physical contiguous memory area (as > > obtained from /proc/iomem) instead of per zone, then number of elf > > headers will come down significantly. > > A clarification on terminology we are talking about struct Elf64_Phdr > here. There is only one Elf header. That seems to be clear farther > down. > Exactly. There shall be one Elf header for whole of the image. In addition there will be one struct Elf64_Phdr, per contiguous physical memory area. One Elf64_Phdr of PT_NOTE type for notes section and one Elf64_Phdr for backup region. > > I don't have any idea on number of > > actual physically contiguous regions present per machine, but roughly > > assuming it to be 1 per node, it will lead to 256 + 1024 = 1280 program > > headers.At 56 bytes per 64 bit program header this will amount to 70KB. > > > > This is worst case estimate and on lower end machines this will require > > much less a space. On machines as big as 1024 cpus, this should not be a > > concern, as big machines come with big RAMs. > > Agreed. Size is not the primary issue. There is some clear waste > but that is a secondary concern. Not performing a 1-1 mapping > to the kernel data structures also seems to be a win, as the concepts > are noticeably different. > > > Eric, do you still think that ELF headers are inappropriate to be passed > > across interface boundary. > > I have serious concerns about the kernel generating the ELF headers > and only delivering them after the kernel has crashed. Because > then we run into questions of what information can be trusted. If we > avoid that issue I am not too concerned. I hope, all elf headers once prepared by kexec-tools need not to change later (Cannot think of any piece of information which shall change later). These shall be put in separate segment. And SHA-256 shall take care of authenticity of information after crash. > > > Regarding Backup Region > > ----------------------- > > > > - Kexec user space does the reservation for backup region segment. > > - Purgatory copies the backup data to backup region. (Already > > implemented) > > - A separate elf header is prepared to represent backed up memory > > region. And "offset" field of this program header can contain the actual > > physical address where backup contents are stored. > > I like that. I was thinking a virtual versus physical address > separation. But using the offset field is much more appropriate, > and it leaves us the potential of doing something nice like specifying > the kernels virtual address later on. Looking exclusively at the > offset field to know which memory addresses to dump sounds good. > For now we should have virtual==physical==offset except for the > backup region. For notes section program header, virtual = physical = 0 and "offset" shall point to crash_notes[], so that notes can directly be read by the capture kernel (or user space). Thanks Vivek - 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/
