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). I think somehow we shall have to make kexec-tools Xen aware to take care of Xen special cases. 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? - 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? - 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. Thanks Vivek > --- 0001/kexec/arch/x86_64/crashdump-x86_64.c > +++ 0002/kexec/arch/x86_64/crashdump-x86_64.c 2006-10-12 > 17:52:24.000000000 +0900 > @@ -79,9 +79,11 @@ static int get_kernel_paddr(struct kexec > return 0; > } > } > - fprintf(stderr, "Cannot determine kernel physical load addr\n"); > + info->kern_paddr_start = 0; > + fprintf(stderr, > + "Warning: Cannot determine kernel physical load addr.\n"); > fclose(fp); > - return -1; > + return 0; > } > > /* Hardcoding kernel virtual address and size. While writting > --- > > Any thoughts? > _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
