[Crash-utility] Re: [PATCH 1/2] Add x86_64 linux-2.6.27 support: Catch up the PAGE_OFFSET change.

[Ken'ichi Ohmichi]

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