On 11 November 2014 11:22, Laszlo Ersek <lersek at redhat.com> wrote: > For this reason, the kdump preparation logic in QEMU hardcodes a number > of fields in the kdump header. The direct issue is the "phys_base" > field. Refer to dump.c, functions create_header32(), create_header64(), > and "include/sysemu/dump.h", macro PHYS_BASE (with the replacement text > "0"). > > http://git.qemu.org/?p=qemu.git;a=blob;f=dump.c;h=9c7dad8f865af3b778589dd0847e450ba9a75b9d;hb=HEAD > > http://git.qemu.org/?p=qemu.git;a=blob;f=include/sysemu/dump.h;h=7e4ec5c7d96fb39c943d970d1683aa2dc171c933;hb=HEAD > > This works in most cases, because the guest Linux kernel indeed tends to > be loaded at guest-phys address 0. However, when the guest Linux kernel > is booted on top of OVMF (which has a somewhat unusual UEFI memory map), > then the guest Linux kernel is loaded at 16MB, thereby getting out of > sync with the phys_base=0 setting visible in the KDUMP header. Presumably this is also not going to work for machines other than the x86 PC, where physical memory may well not start at address zero... -- PMM
