Hi Vivek, Thanks for the quick reply!
On 10/12/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > On Thu, Oct 12, 2006 at 06:47:08PM +0900, Magnus Damm wrote: > > Hi Vivek, > > > > This patch breaks kdump under Xen/dom0. This is because "Kernel code" > > isn't listed in /proc/iomem. The reason behind this is probably that > > the address where the kernel is loaded is in pseudo physical address > > space, and this space is not contiguously mapped 1:1 to machine > > addresses (real physical addresses in the Linux world). > > > > If we really want to pass physical addresses under Xen we need to pass > > the address of each and every page that maps the kernel. This sounds > > like a pretty redundant move IMO because the tool that parses Xen > > crash dumps needs to be (and is already) aware of this mapping anyhow. > > > > So the following (mangled) patch fixes this by warning instead of > > returning error: > > > > Magnus, I think this patch is problematic. This bypasses the > error checking mechanism in non-virtualized env. So due to some reason if > "Kernel Code" is not exported from /proc/iomem, kexec-tools will never > detect it and set the phyaddr to zero. And a kernel header will be created > with kernel virtual address X pointing to physical addr 0 which is wrong. > It should have been kernel virtual addr X pointing to physical addr 2MB > (Assuming kernel is loaded physically at 2MB addr). Yeah, I agree that the broken elf header is far from good. It was mostly a quick fix to be able to continue to use kexec-tools to kdump on x86_64. > I think somehow we shall have to make kexec-tools Xen aware to take care > of Xen special cases. So far we've been able to use an unmodified / generic version of kexec-tools under Xen/dom0. This has been very nice as it has given us more time to focus on the kernel side. Maybe now is a good time to put in some Xen knowledge into kexec-tools. I would like to keep things as simple as possible - especially the kernel code. I believe that the right solution is to put as much knowledge into the tool that analyzes the crash dump instead of adding things to the kernel. A good example on how things get complicated in the Xen case is the crash notes. The crash notes are per physical cpu, but the cpu:s that linux sees are all virtual cpus under Xen/dom0. So we could either create/use some interface between dom0 and the hypervisor to get that mapping and export that interface to userspace and kexec-tools, OR we can just simply scrap the crash notes in the Xen case. I'm all in favor for that solution, and instead we keep a per cpu structure in the hypervisor visible to the analysis tool as a global symbol in hypervisor space. 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. > 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. > - 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? The Xen crash dump is a snapshot of all physical memory. To extract the hypervisor or domains the Xen crash analysis tools dom0cut and dumpread can be used. > - How do you create the ELF header for kernel? I mean where kernel > is mapped in physical addr space. As per your description it looks like > you don't even know in user space, the actual physical addresses for > kernel. May be the dumpread utility takes care of reconstructing the > headers for you. For normal dumps we don't have to run any such > additional utility. That's where I think the need arise to make > kexec-tools Xen aware. It is correct that we don't know the actual physical address (machine address in Xen lingo) for each page - especially not in userspace. And why should we? The dumpread/dom0cut tools are used to create "standard" elfcore dump files for us. Not sure how they handle physical addresses and elf headers, but they have enough information in the Xen crash dump to create whatever needed. Thanks, / magnus _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
