[Crash-utility] Re: [PATCH 1/2] Add x86_64 linux-2.6.27 support: Catch up the PAGE_OFFSET change.
Ken'ichi Ohmichi wrote:
Hi Dave,
[ snip ]
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)
$
Well there may be a couple issues with that approach. First, we need
a way to handle/recognize it on live systems. And second, I believe we'll need
a way to differentiate a pv_ops/xen kernel from a "dedicated" xen kernel.
And my guess is that the vmcore notes will not differentiate between the
two "flavors" of xen kernel (unless there's an entry in the VMCOREINFO_XEN
that will somehow differentiate the two).
I'm thinking now that a pv_ops/xen kernel should not be simply handled by
making the current XEN() macro usable. Looking at the various usages of XEN(),
I think that many of them may *only* be applicable to dedicated xen kernels.
So I believe there should be a new PV_XEN() macro, and ultimately PV_KVM()
and PV_VMI() macros. Given that all of the pv_ops kernels are the "same"
vmlinux, it's possible that in some ways things may be simplified. But I
strongly doubt that the use of the current XEN() macro will work.
So I think it's best to take it one step at a time. The first step will be
to get crash working with 2.6.27 bare-metal kernels, and disallow the setting
of the ARCH_XEN flag used by the XEN() macro. Until I actually see a "real"
pv_ops/xen kernel dumpfile, it's not even worth pre-coding for it.
Dave