On Mon, Oct 16, 2006 at 05:56:54PM +0900, Magnus Damm wrote: > > > >> Please bear in mind that our perspective here is the _entire_ system > >> with both the hypervisor and domains. It seems to me like kexec-tools > >> is kind of linux-centric and adds various pieces of information to the > >> elf header depending on the running kernel. That's great for Linux - > >> but in the Xen case there is no point in trying to fill in a physical > >> address range for the kernel that doesn't even exist. Especially since > >> the dump if for the entire system. Maybe it would make sense to have a > >> physical address range for the hypervisor, but until Xen is > >> relocatable I see no point in adding it. > >> > > > >Does that mean that currently you are creating ELF headers for only the > >physical memory used by dom0 and Xen hypervisor only? > > Well, we are not doing anything special - just using the standard > version of kexec-tool. This probably means that the ELF headers are > wrong right now. >
I have not used kexec-tools in Xen env, but I think if you are using it unmodified, then it will create PT_LOAD type program headers for all the physical memory visible through /proc/iomem. It will also create PT_NOTE type program header which will point to various elf notes containing cpu register states. Currently the address of kernel memory ,where cpu state will be saved, is read from /sys/.... Now I don't know what is exported through /sys/devices/system/cpu/cpu[n]/crash_notes. Logically speaking it should be the addresses where virtual cpu state will be saved upon crash. > >> >I got few basic questions. > >> > > >> >- What is exported through /proc/iomem in Xen dom0. Chunks of RAM, are > >> >these > >> > pseudo physical addresses or actual physical addresses? > >> > >> Actual physical addresses. But no kernel addresses because they are > >> not actual physical addresses. Under Xen I think that we shouldn't > >> create such a header at all. > >> > > > >These are the physical addresses for memory used by dom0 or physical > >address for all the memory present in the system? > > The entire system. > > >Given the nature of crash dump in Xen, I think it makes sense to just > >create ELF headers for all the physical memory present in the system > >and don't create ELF notes for the cpu register states. Let a user space > >utility later re-create the system state based on what partition dump > >user is looking for. > > That sounds like a good and simple. I must confess that I'm a bit > confused by all types of ELF headers, do you have any recommendation > which headers that should be present? > You have to just create PT_LOAD type headers for all the contiguous physical memory chunks. > >> >- How do you create ELF headers for Xen dom0? I am assuming that you are > >> > dumping whole of the physical memory when dom0 or hypervisor crashes. > >> > From where do you get the info about all the physical memory? > >> > >> I suppose kexec-tools sets up enough information to make /proc/vmcore > >> point out the correct amount of physical memory in the secondary crash > >> kernel. Not sure if it is correct, but we are doing things as similar > >> to standard Linux as possible. Not sure if it is such a good idea that > >> if now kexec-tools sets up the amount of memory - what about memory > >> hotplug? > >> > > > >Yes, kexec-tools sets up ELF headers for the physical memory visible > >through /proc/iomem. So if dom0 /proc/iomem is exporting all the physical > >memory present in the system not just the memory being used by dom0 then > >ELF headers will be set up for all the RAM present in the system. > > This is what happens today if I'm not mistaken. > > >For memory hot plug, kdump kernel needs to be reloaded. I think some > >hotplug memory agent in user space can do that. Last time I checked, I > >could not find any hotplug memory agent yet. Somebody said it is yet to > >be written. > > Yeah, reloading the kernel should solve the problem. With memory > hotplug as example I wanted to highlight some problem the regular > Linux port may run into on bare metal because of the current kexec / > kdump architecture. Compare the current memory solution with say, > parsing e820 tables in-kernel and the memory-world-view-out-of-sync > problem would go away. > > I feel that the current architecture with kexec-tools, purgatory, > kernel and crash tools may be complicated for no apparent reason. But > this feeling may just be because I'm trying to cram Xen into the > mix... =) > > Anyway, exporting hardware information only in the Xen case sounds > like the way to go, right? > By hardware info, you mean whole of the RAM info, then yes. Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
