Re: kdump with xen-unstable on efi machine

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/11/14 14:01, Juergen Gross wrote:
> On 11/26/2014 01:41 PM, Andrew Cooper wrote:
>> On 26/11/14 12:15, Juergen Gross wrote:
>>> Hi,
>>>
>>> I tried to enable kdump on my test-machine with actual xen-unstable
>>> booting via EFI.
>>>
>>> The kdump kernel is not being loaded.
>>>
>>> I'm seeing the memory being reserved:
>>>
>>> (XEN) EFI RAM map:
>>> (XEN)  0000000000000000 - 00000000000a0000 (usable)
>>> (XEN)  0000000000100000 - 000000004bc00000 (usable)
>>> (XEN)  000000004bc00000 - 000000005bc00000 (reserved)
>>> (XEN)  000000005bc00000 - 000000005bfec000 (usable)
>>> (XEN)  000000005bfec000 - 000000005c000000 (ACPI NVS)
>>> (XEN)  000000005c000000 - 000000006a429000 (usable)
>>> (XEN)  000000006a429000 - 000000006a42c000 (reserved)
>>> (XEN)  000000006a42c000 - 000000006a7a2000 (usable)
>>> (XEN)  000000006a7a2000 - 000000006a7a8000 (reserved)
>>> (XEN)  000000006a7a8000 - 000000006a987000 (usable)
>>> (XEN)  000000006a987000 - 000000006a98d000 (reserved)
>>> (XEN)  000000006a98d000 - 000000006aa63000 (usable)
>>> (XEN)  000000006aa63000 - 000000006aa73000 (reserved)
>>> (XEN)  000000006aa73000 - 000000006ac60000 (usable)
>>> (XEN)  000000006ac60000 - 000000006ac61000 (reserved)
>>> (XEN)  000000006ac61000 - 000000006ac9b000 (ACPI data)
>>> (XEN)  000000006ac9b000 - 000000006acac000 (reserved)
>>> (XEN)  000000006acac000 - 000000006acad000 (usable)
>>> (XEN)  000000006acad000 - 000000006acae000 (reserved)
>>> (XEN)  000000006acae000 - 000000007189c000 (usable)
>>> (XEN)  000000007189c000 - 0000000071946000 (reserved)
>>> (XEN)  0000000071946000 - 0000000072d76000 (ACPI NVS)
>>> (XEN)  0000000072d76000 - 0000000072db2000 (ACPI data)
>>> (XEN)  0000000072db2000 - 0000000072edc000 (usable)
>>> (XEN)  0000000080000000 - 0000000090000000 (reserved)
>>> (XEN)  0000000100000000 - 0000002080000000 (usable)
>>> (XEN) Kdump: 256MB (262144kB) at 0x206dff4000
>>>
>>> I'd expect this area being visible in the efi or e820 map presented to
>>> dom0, but I can't see anything:
>>
>> This is expected.  The dom0 kernel now has nothing at all do with
>> loading crash kernel.  Loading happens via hypercalls straight from the
>> kexec utility.
>>
>> You need kexec-tools 2.0.4 (I think) or later, compiled with Xen
>> support, but it should JustWork.
>
> Should. I have kexec 2.0.5 with Xen support. Doesn't work:
>
> Excerpt form strace:
>
> "sysctl operation failed -- need to rebuild the user-space tool set?\n"
>
> My personal translation: kexec is tightly coupled to the Xen version
> (this one was built against Xen 4.4.1 AFAIK).

It uses libxc, so needs to be built from the same source.

>
> Perhaps we should add kexec to the tools directory?

The tools directory, and this willingness to fork other projects and
keep a local copy, is the primary driver behind this situation being as
dire as it is.

libxc (or some new alternative) should suck it up and gain some notion
of a stable API or ABI (like the rest of the world appears to be able to
manage), such that it is possible to compile with an older header and
use a newer .so at runtime.

~Andrew