RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Dexuan Cui]

> From: Michael Kelley <mhklinux@xxxxxxxxxxx>
> Sent: Thursday, January 22, 2026 10:39 PM
>  ...
> This is good info, and definitely a clue. So to be clear, the problem repros
> only when kexec_load() is used. With kexec_file_load(), it does not repro. Is
> that right?

Yes and no. The answer depends on the combination of the version of
kdump-tools, and the architecture (x86-64 vs. ARM64), and the hypercall
(KEXEC_LOAD vs. KEXEC_FILE_LOAD)  and the Linux kernel version (there
have been patches fixing and breaking kdump over the past several years...)

Please see the reply I posted about 2 hours ago for all the details. 

> I saw a similar distinction when working on commit 304386373007,
> though in the opposite direction!
I think this happens because you're using Ubuntu 20.04:

> https://lwn.net/ml/linux-kernel/SN6PR02MB41572155B6D139C499814EB7D4F12@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> To further complicate matters, the kexec on Oracle Linux 9.4 seems to
> have a bug when the -c option forces the use of kexec_load() instead
> of kexec_file_load(). As an experiment, I modified the kdumpctl shell
> script to add the "-c" option to kexec, but in that case the value "0x0"
> is passed as the framebuffer address, which is wrong.

Before commit 304386373007, hyperv_fb relocates the framebuffer
MMIO base,  so KEXEC_FILE_LOAD doesn't work for you, because the kdump
kernel's screen_info.lfb_base still points to the initial MMIO, and hence
the kdump kernel's efifb driver fails to work properly; KEXEC_LOAD works
for you because the kdump-tools v2.0.18 in Ubuntu 20.04 doesn't have that
commit (see the other reply from me)

The kexec on Oracle Linux 9.4 has that commit, and it's not buggy -- unless
we'd like to claim that all the recent kdump-tools versions are buggy :-)

Thanks,
Dexuan