RE: [PATCH 2/2] drm/hyperv: During panic do VMBus unload after frame buffer is flushed

[<mhklkml@zohomail.com>]

From: Jocelyn Falempe <jfalempe@redhat.com> Sent: Wednesday, February 11, 2026 1:54 PM
> 
> On 09/02/2026 08:02, mhkelley58@gmail.com wrote:
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > 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 <jfalempe@redhat.com>
> 
> 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 <mhklinux@outlook.com>
> > ---
> >   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.

Michael

> 
> > +		vmbus_set_skip_unload(true);
> >   	drm_client_setup(dev, NULL);
> >
> >   	return 0;