Hi Oda-san,
We have a problem with the RHEL5.2 xen hypervisor kdump vmcores.
The RHEL5.2 hypervisor sources have been upgraded to xen version 3.1.2,
and the x86_64 hypervisor is now relocatable to a dynamically-determined
physical address at boot-time. That being the case, the crash utility
cannot possibly work with xen-syms/vmcore pairs without knowing how to
translate hypervisor virtual addresses to their physical counterparts.
The makedumpfile utility would run into the same problem.
I suspect you may have seen this working with upstream xen?
This is how I understand it:
Prior to RHEL5.2, the hypervisor's text and static data region was
direct-mapped. There was (and still is) a direct-mapped region defined
like so:
DIRECTMAP_VIRT_START 0xffff830000000000
DIRECTMAP_VIRT_END 0xffff840000000000
and the hypervisor text and static data was located inside of that
direct-mapped region:
# nm -Bn xen-syms-2.6.18-53.el5.debug
ffff830000100000 A _start
ffff830000100000 A _stext
ffff830000100000 T start
ffff830000100048 t bad_cpu
ffff83000010004f t not_multiboot
ffff830000100054 t print_err
ffff830000100075 t __start
... [ snip ] ...
ffff83000020e6e0 b model
ffff83000020e700 b cpu_msrs
ffff83000020e900 b saved_lvtpc
ffff83000020ea00 b reset_value
ffff83000020ea40 b reset_value
ffff83000020ea60 b reset_value
ffff83000020ea80 A _end
#
Because hypervisor text/static-data it was direct-mapped, the
virtual-to-physical address translation was simple -- only requiring
that the DIRECTMAP_VIRT_START identifier (0xffff830000000000) be
subtracted from the virtual address, leaving the physical address.
In the upgraded RHEL5.2 hypervisor, the kernel text and static data
is dynamically relocated at boot time, to a location that is based
upon the physical memory layout of the host machine. It has its own
1GB mapped region, that exists here:
XEN_VIRT_START 0xffff828c80000000
XEN_VIRT_END 0xffff828cc0000000
# nm -Bn xen-syms-2.6.18-89.el5.debug
ffff828c80100000 A _start
ffff828c80100000 A _stext
ffff828c80100000 T start
ffff828c80100014 t __high_start
ffff828c801000b7 t int_msg
ffff828c801000d7 t hex_msg
... [ snip ] ...
ffff828c8024e4a0 b cpu_msrs
ffff828c8024e8a0 b saved_lvtpc
ffff828c8024eaa0 b cpu_type
ffff828c8024eac0 b reset_value
ffff828c8024eb00 b reset_value
ffff828c8024eb20 b reset_value
ffff828c8024eb40 A _end
#
So translating hypervisor virtual addresses to their physical
address can no longer be done by simply subtracting a direct-map
identifier like before.
Note that the hypervisor code's new version of __pa(), for example,
ends up doing this:
if ( va > DIRECTMAP_VIRT_START )
return va - DIRECTMAP_VIRT_START;
return va - XEN_VIRT_START + xen_phys_start;
where the value of "xen_phys_start" is the base physical address
of the relocated hypervisor text and static data.
Again, there is the problem -- when crash is looking at a xen-syms
binary and a vmcore, it does not know the value of "xen_phys_start"
and therefore cannot translate hypervisor virtual addresses, and
therefore is completely useless.
It seems to me that the xen kdump mechanism needs to be modified
to store the "xen_phys_start" value in the vmcore someplace?
Do have any thoughts on how best to address this?
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
