On 12/02/2026 00:01, [email protected] wrote:
From: Jocelyn Falempe <[email protected]> Sent: Wednesday, February 11, 2026
1:54 PM
On 09/02/2026 08:02, [email protected] wrote:
From: Michael Kelley <[email protected]>
In a VM, Linux panic information (reason for the panic, stack trace,
etc.) may be written to a serial console and/or a virtual frame buffer
for a graphics console. The latter may need to be flushed back to the
host hypervisor for display.
The current Hyper-V DRM driver for the frame buffer does the flushing
*after* the VMBus connection has been unloaded, such that panic messages
are not displayed on the graphics console. A user with a Hyper-V graphics
console is left with just a hung empty screen after a panic. The enhanced
control that DRM provides over the panic display in the graphics console
is similarly non-functional.
Commit 3671f3777758 ("drm/hyperv: Add support for drm_panic") added
the Hyper-V DRM driver support to flush the virtual frame buffer. It
provided necessary functionality but did not handle the sequencing
problem with VMBus unload.
Fix the full problem by using VMBus functions to suppress the VMBus
unload that is normally done by the VMBus driver in the panic path. Then
after the frame buffer has been flushed, do the VMBus unload so that a
kdump kernel can start cleanly. As expected, CONFIG_DRM_PANIC must be
selected for these changes to have effect. As a side benefit, the
enhanced features of the DRM panic path are also functional.
Thanks for properly fixing this issue with DRM Panic on hyperv.
I've a small comment below.
With that fixed:
Reviewed-by: Jocelyn Falempe <[email protected]>
The first patch looks good too, I can review it if no other step up, as
I'm not familiar with hyperv.
Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
Signed-off-by: Michael Kelley <[email protected]>
---
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 4 ++++
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 15 ++++++++-------
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 06b5d96e6eaf..79e51643be67 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -150,6 +150,9 @@ static int hyperv_vmbus_probe(struct hv_device *hdev,
goto err_free_mmio;
}
+ /* If DRM panic path is stubbed out VMBus code must do the unload */
+ if (IS_ENABLED(CONFIG_DRM_PANIC) && IS_ENABLED(CONFIG_PRINTK))
I think drm_panic should still work without printk.
The "user" panic screen would be unaffected, but the "kmsg" screen might
be blank, and the "qr_code" would generate an empty qr code.
(Actually I never tried to build a kernel without printk).
Yeah, I had never built such a kernel either until recently when the kernel
test robot flagged an error in Hyper-V code when CONFIG_PRINTK is not set. :-)
But for this patch, the issue is that drm_panic() never gets called if
CONFIG_PRINTK
isn't set. In that case, kmsg_dump_register() is a stub that returns an error.
So
drm_panic_register() never registers the callback to drm_panic(). And if
drm_panic() isn't going to run, responsibility for doing the VMBus unload
must remain with the VMBus code. It's hard to actually test this case because
of depending on printk() for debugging output, so double-check my
thinking.
Ok you're right. I changed from
atomic_notifier_chain_register(&panic_notifier_list, ...) to
kmsg_dump_register() in the v10 of drm_panic.
So I should either make DRM_PANIC depends on PRINTK, or call
atomic_notifier_chain_register() if PRINTK is not defined.
As I think kernel without PRINTK are uncommon, I'll probably do the
first solution.
--
Jocelyn
Michael
+ vmbus_set_skip_unload(true);
drm_client_setup(dev, NULL);
return 0;
