[Crash-utility] Re: [PATCH 1/2] Add x86_64 linux-2.6.27 support: Catch up the PAGE_OFFSET change.
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