@vkuznets do you believe this is something is in our domain to fix?

It seems this is a dracut issue.

/usr/lib/dracut/modules.d/50drm/module-setup.sh has the following code:

...
    instmods amdkfd hyperv_fb "=drivers/pwm"

    # if the hardware is present, include module even if it is not currently loaded,
    # as we could e.g. be in the installer; nokmsboot boot parameter will disable
    # loading of the driver if needed
    if [[ $hostonly ]]; then
        for i in /sys/bus/{pci/devices,platform/devices,virtio/devices,soc/devices/soc?}/*/modalias; do
            [[ -e $i ]] || continue
            [[ -n $(< "$i") ]] || continue
            # shellcheck disable=SC2046
            if hostonly="" dracut_instmods --silent -s "drm_crtc_init|drm_dev_register|drm_encoder_init" -S "iw_handler_get_spy" $(< "$i"); then
                if strstr "$(modinfo -F filename $(< "$i") 2> /dev/null)" radeon.ko; then
                    hostonly='' instmods amdkfd
                fi
            fi
        done
    else
        dracut_instmods -o -s "drm_crtc_init|drm_dev_register|drm_encoder_init" "=drivers/gpu/drm" "=drivers/staging"
    fi
...

So 'hyperv_fb' is included explicitly and hyperv_drm is not a virtio/PCI device
(with Gen2 VMs)

I'd suggest to add '/sys/bus/vmbus/devices/' to the search list, i.e.:
...
    if [[ $hostonly ]]; then
        for i in /sys/bus/{pci/devices,platform/devices,virtio/devices,soc/devices/soc?,vmbus/devices}/*/modalias; do
...

This seems to work for me. Reassigning to dracut.

Vitaly, thanks for your inputs.  If anything need to do in kexec-tools please feel free to move back.

(In reply to Vitaly Kuznetsov from comment #2)
> I'd suggest to add '/sys/bus/vmbus/devices/' to the search list, i.e.:
> ...
>     if [[ $hostonly ]]; then
>         for i in
> /sys/bus/{pci/devices,platform/devices,virtio/devices,soc/devices/soc?,vmbus/
> devices}/*/modalias; do
> ...

Sounds reasonable to me.

https://github.com/dracutdevs/dracut/pull/1917

Checked with dracut-057-13.git20220816.el9.x86_64
1. Install dracut-057-13.git20220816.el9.x86_64
2. Rebuild kdump.img
3. Check the hyperv_drm was included in kdump initramfs
4. Restart kdump.service and trigger kdump
5. Check log display on console 

[root@vm-197-36 ~]# lsinitrd /boot/initramfs-$(uname -r)kdump.img | grep hyperv_drm
[root@vm-197-36 ~]# dracut -f /boot/initramfs-$(uname -r)kdump.img $(uname -r)
[root@vm-197-36 ~]# lsinitrd /boot/initramfs-$(uname -r)kdump.img | grep hyperv_drm
-rw-r--r--   1 root     root        23736 Aug 11 00:34 usr/lib/modules/5.14.0-145.el9.x86_64/kernel/drivers/gpu/drm/hyperv/hyperv_drm.ko.xz
[root@vm-197-36 ~]#systemctl restart kdump.service
[root@vm-197-36 ~]# echo c > /proc/sysrq-trigger


Will check with this again when the new compose build available.

Checked with compose: RHEL-9.1.0-20220817.6_x86_64 GEN2 VM， now the console can display the kdump log before reboot. issue fixed

[root@vm-197-199 ~]# uname -r
5.14.0-145.el9.x86_64
[root@vm-197-199 ~]# rpm -qa dracut
dracut-057-13.git20220816.el9.x86_64
[root@vm-197-199 ~]# lsinitrd /boot/initramfs-$(uname -r)kdump.img | grep hyperv_drm
-rw-r--r-- root/root             23736 2022-08-11 00:34 squashfs-root/usr/lib/modules/5.14.0-145.el9.x86_64/kernel/drivers/gpu/drm/hyperv/hyperv_drm.ko.xz
[root@vm-197-199 ~]# systemctl status kdump.service
● kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2022-08-18 20:10:46 CST; 4min 6s ago
    Process: 837 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
   Main PID: 837 (code=exited, status=0/SUCCESS)
        CPU: 1.342s

Aug 18 20:10:43 vm-197-199.lab.eng.pek2.redhat.com systemd[1]: Starting Crash recovery kernel arming...
Aug 18 20:10:46 vm-197-199.lab.eng.pek2.redhat.com kdumpctl[936]: kdump: kexec: loaded kdump kernel
Aug 18 20:10:46 vm-197-199.lab.eng.pek2.redhat.com kdumpctl[936]: kdump: Starting kdump: [OK]
Aug 18 20:10:46 vm-197-199.lab.eng.pek2.redhat.com systemd[1]: Finished Crash recovery kernel arming.
[root@vm-197-199 ~]# echo c > /proc/sysrq-trigger

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dracut bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8379