Hi Dave, Thank you for checking my patch. Dave Anderson wrote: > However, there is a problem with your patch such that it won't work > with the sample Fedora kernel that I was planning to use as a test case. > That kernel is this Fedora version: > > Linux version 2.6.27-0.244.rc2.git1.fc10.x86_64 > > When I run with your patches, I still get the same initialization > time failure: > > crash: cannot resolve: "end_pfn" > > With the Fedora kernel, your changes to x86_64_init() are not executed because > the VM_2_6_11 flag does not get set here, but rather VM_XEN get set: [snip] > Now, clearly the linux-2.6.27-rc5 vmlinux that you used for testing your > patch does *not* have the "xen_start_info" symbol contained in it, because > if it did, you would have run into the same problem as me. I'm guessing > that all of the xen symbols I seen in my kernel are due to a CONFIG-option > used by the Fedora kernel build? And perhaps the same thing is done for KVM? > (VMI?) By any chance, do you know exactly how the pv_ops implementations fit > together? I could reproduce the same problem. As you guessed, my vmlinux had been built without the following CONFIG items: - CONFIG_PARAVIRT_GUEST=y - CONFIG_XEN=y - CONFIG_XEN_MAX_DOMAIN_MEMORY=32 - CONFIG_XEN_SAVE_RESTORE=y - CONFIG_KVM_CLOCK=y - CONFIG_KVM_GUEST=y - CONFIG_PARAVIRT=y - CONFIG_PARAVIRT_CLOCK=y Then, I built a vmlinux with these items, and I saw the same problem that the crash with my patch cannot run when the initialization time: crash: cannot resolve: "end_pfn" We should fix it. > In any case, the benefit of the pv_ops implementation is supposed to be > the fact that the same vmlinux kernel can be used for bare-metal or virtualized > kernels, but it potentially makes things more difficult for the crash > utility. But given that the bare-metal/virualized kernels are identical, then > presumably the kernel's PAGE_OFFSET would be identical, and that's what your patch > is addressing. However, crash will also need a way to determine whether > it's a xen kernel or not. For example, look at the crash sources for all > users of the XEN() macro. > > So I'm thinking that there may have to be something like a new > virtualization_init() function called very early on that can determine > whether this kernel is a newer pv_ops kernel with xen, kvm, etc. possibly > built-in? So in your linux-2.6.27-rc5 vmlinux, the new function would see the > pv_ops symbols but no xen symbols, so it could set some "bare-metal" flag. > But in the Fedora kernel's case, it would see both pv_ops and xen symbols, > and then would have to actually read (if possible) the xen_start_info pointer > to see if it's been initialized to something -- hopefully without getting into > a chicken-and-egg situation. Worst case, it may require new crash command line > arguments such as --xen or --kvm. But I'm hoping to avoid that if at all possible. I think that a new virtualization_init() function is a good idea. How about checking whether "Xen" exists in PT_NOTE section of an vmcore at virtualization_init()? I feel that it is safer than reading a xen_start_info pointer. $ readelf -n vmcore Notes at offset 0x00000120 with length 0x00001388: Owner Data size Description CORE 0x00000150 NT_PRSTATUS (prstatus structure) Xen 0x00000020 Unknown note type: (0x01000002) <----- HERE CORE 0x00000150 NT_PRSTATUS (prstatus structure) Xen 0x00000020 Unknown note type: (0x01000002) <----- HERE Xen 0x00000050 Unknown note type: (0x01000001) <----- HERE VMCOREINFO_XEN 0x00000fe4 Unknown note type: (0x00000000) $ Thanks Ken'ichi Ohmichi -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
