On 10/16/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > 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.
Thanks for the detailed explanation. Our xen patch currently exports hypervisor crash notes in /sys/devices/system/cpu/.../crash_notes, but they might be removed in the near future for the Xen case. > > >> >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. Ok. I will try to hack up a patch that does just that then. > > >> >- 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. Yes, that's what I mean. Many thanks! / magnus _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
