[PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic

[PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic

[mhkelley58]

From: Michael Kelley <mhklinux@outlook.com>

Currently, VMBus code initiates a VMBus unload in the panic path so
that if a kdump kernel is loaded, it can start fresh in setting up its
own VMBus connection. However, a driver for the VMBus virtual frame
buffer may need to flush dirty portions of the frame buffer back to
the Hyper-V host so that panic information is visible in the graphics
console. To support such flushing, provide exported functions for the
frame buffer driver to specify that the VMBus unload should not be
done by the VMBus driver, and to initiate the VMBus unload itself.
Together these allow a frame buffer driver to delay the VMBus unload
until after it has completed the flush.

Ideally, the VMBus driver could use its own panic-path callback to do
the unload after all frame buffer drivers have finished. But DRM frame
buffer drivers use the kmsg dump callback, and there are no callbacks
after that in the panic path. Hence this somewhat messy approach to
properly sequencing the frame buffer flush and the VMBus unload.

Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
 drivers/hv/channel_mgmt.c |  1 +
 drivers/hv/hyperv_vmbus.h |  1 -
 drivers/hv/vmbus_drv.c    | 25 ++++++++++++++++++-------
 include/linux/hyperv.h    |  3 +++
 4 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 74fed2c073d4..5de83676dbad 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -944,6 +944,7 @@ void vmbus_initiate_unload(bool crash)
 	else
 		vmbus_wait_for_unload();
 }
+EXPORT_SYMBOL_GPL(vmbus_initiate_unload);
 
 static void vmbus_setup_channel_state(struct vmbus_channel *channel,
 				      struct vmbus_channel_offer_channel *offer)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index cdbc5f5c3215..5d3944fc93ae 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -440,7 +440,6 @@ void hv_vss_deinit(void);
 int hv_vss_pre_suspend(void);
 int hv_vss_pre_resume(void);
 void hv_vss_onchannelcallback(void *context);
-void vmbus_initiate_unload(bool crash);
 
 static inline void hv_poll_channel(struct vmbus_channel *channel,
 				   void (*cb)(void *))
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 6785ad63a9cb..97dfa529d250 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -69,19 +69,29 @@ bool vmbus_is_confidential(void)
 }
 EXPORT_SYMBOL_GPL(vmbus_is_confidential);
 
+static bool skip_vmbus_unload;
+
+/*
+ * Allow a VMBus framebuffer driver to specify that in the case of a panic,
+ * it will do the VMbus unload operation once it has flushed any dirty
+ * portions of the framebuffer to the Hyper-V host.
+ */
+void vmbus_set_skip_unload(bool skip)
+{
+	skip_vmbus_unload = skip;
+}
+EXPORT_SYMBOL_GPL(vmbus_set_skip_unload);
+
 /*
  * The panic notifier below is responsible solely for unloading the
  * vmbus connection, which is necessary in a panic event.
- *
- * Notice an intrincate relation of this notifier with Hyper-V
- * framebuffer panic notifier exists - we need vmbus connection alive
- * there in order to succeed, so we need to order both with each other
- * [see hvfb_on_panic()] - this is done using notifiers' priorities.
  */
 static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
 			      void *args)
 {
-	vmbus_initiate_unload(true);
+	if (!skip_vmbus_unload)
+		vmbus_initiate_unload(true);
+
 	return NOTIFY_DONE;
 }
 static struct notifier_block hyperv_panic_vmbus_unload_block = {
@@ -2848,7 +2858,8 @@ static void hv_crash_handler(struct pt_regs *regs)
 {
 	int cpu;
 
-	vmbus_initiate_unload(true);
+	if (!skip_vmbus_unload)
+		vmbus_initiate_unload(true);
 	/*
 	 * In crash handler we can't schedule synic cleanup for all CPUs,
 	 * doing the cleanup for current CPU only. This should be sufficient
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index dfc516c1c719..b0502a336eb3 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1334,6 +1334,9 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 			bool fb_overlap_ok);
 void vmbus_free_mmio(resource_size_t start, resource_size_t size);
 
+void vmbus_initiate_unload(bool crash);
+void vmbus_set_skip_unload(bool skip);
+
 /*
  * GUID definitions of various offer types - services offered to the guest.
  */
-- 
2.25.1

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

[mhkelley58]

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.

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))
+		vmbus_set_skip_unload(true);
 	drm_client_setup(dev, NULL);
 
 	return 0;
@@ -169,6 +172,7 @@ static void hyperv_vmbus_remove(struct hv_device *hdev)
 	struct drm_device *dev = hv_get_drvdata(hdev);
 	struct hyperv_drm_device *hv = to_hv(dev);
 
+	vmbus_set_skip_unload(false);
 	drm_dev_unplug(dev);
 	drm_atomic_helper_shutdown(dev);
 	vmbus_close(hdev->channel);
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
index 7978f8c8108c..d48ca6c23b7c 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
@@ -212,15 +212,16 @@ static void hyperv_plane_panic_flush(struct drm_plane *plane)
 	struct hyperv_drm_device *hv = to_hv(plane->dev);
 	struct drm_rect rect;
 
-	if (!plane->state || !plane->state->fb)
-		return;
+	if (plane->state && plane->state->fb) {
+		rect.x1 = 0;
+		rect.y1 = 0;
+		rect.x2 = plane->state->fb->width;
+		rect.y2 = plane->state->fb->height;
 
-	rect.x1 = 0;
-	rect.y1 = 0;
-	rect.x2 = plane->state->fb->width;
-	rect.y2 = plane->state->fb->height;
+		hyperv_update_dirt(hv->hdev, &rect);
+	}
 
-	hyperv_update_dirt(hv->hdev, &rect);
+	vmbus_initiate_unload(true);
 }
 
 static const struct drm_plane_helper_funcs hyperv_plane_helper_funcs = {
-- 
2.25.1

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

[Jocelyn Falempe]

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).

> +		vmbus_set_skip_unload(true);
>   	drm_client_setup(dev, NULL);
>   
>   	return 0;
> @@ -169,6 +172,7 @@ static void hyperv_vmbus_remove(struct hv_device *hdev)
>   	struct drm_device *dev = hv_get_drvdata(hdev);
>   	struct hyperv_drm_device *hv = to_hv(dev);
>   
> +	vmbus_set_skip_unload(false);
>   	drm_dev_unplug(dev);
>   	drm_atomic_helper_shutdown(dev);
>   	vmbus_close(hdev->channel);
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> index 7978f8c8108c..d48ca6c23b7c 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> @@ -212,15 +212,16 @@ static void hyperv_plane_panic_flush(struct drm_plane *plane)
>   	struct hyperv_drm_device *hv = to_hv(plane->dev);
>   	struct drm_rect rect;
>   
> -	if (!plane->state || !plane->state->fb)
> -		return;
> +	if (plane->state && plane->state->fb) {
> +		rect.x1 = 0;
> +		rect.y1 = 0;
> +		rect.x2 = plane->state->fb->width;
> +		rect.y2 = plane->state->fb->height;
>   
> -	rect.x1 = 0;
> -	rect.y1 = 0;
> -	rect.x2 = plane->state->fb->width;
> -	rect.y2 = plane->state->fb->height;
> +		hyperv_update_dirt(hv->hdev, &rect);
> +	}
>   
> -	hyperv_update_dirt(hv->hdev, &rect);
> +	vmbus_initiate_unload(true);
>   }
>   
>   static const struct drm_plane_helper_funcs hyperv_plane_helper_funcs = {

-- 

Jocelyn

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

[mhklkml]

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;

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

[Jocelyn Falempe]

On 12/02/2026 00:01, mhklkml@zohomail.com wrote:
> 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.

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;
> 

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

[Jocelyn Falempe]

On 12/02/2026 10:49, Jocelyn Falempe wrote:
> On 12/02/2026 00:01, mhklkml@zohomail.com wrote:
>> From: Jocelyn Falempe <jfalempe@redhat.com> Sent: Wednesday, February 
>> 11, 2026 1:54 PM
>>
>> 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.
> 

FYI, I just sent the corresponding change:

https://patchwork.freedesktop.org/series/161544/

Best regards,

--

Jocelyn

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

[Michael Kelley]

From: Jocelyn Falempe <jfalempe@redhat.com> Sent: Thursday, February 12, 2026 2:10 AM
> 
> On 12/02/2026 10:49, Jocelyn Falempe wrote:
> > On 12/02/2026 00:01, mhklkml@zohomail.com wrote:
> >> From: Jocelyn Falempe <jfalempe@redhat.com> Sent: Wednesday, February
> >> 11, 2026 1:54 PM
> >>
> >> 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.
> >
> 
> FYI, I just sent the corresponding change:
> 
> https://patchwork.freedesktop.org/series/161544/
> 

Works for me. That means I can drop the CONFIG_PRINTK condition
from my patch, which would be good. The current version is rather
strange in that regard. I'm pretty tied up the rest of this week,
so it may be next week before I resubmit my patches.

Michael

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

[Long Li]

> 
> 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.
> 
> Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>

Reviewed-by: Long Li <longli@microsoft.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))
> +		vmbus_set_skip_unload(true);
>  	drm_client_setup(dev, NULL);
> 
>  	return 0;
> @@ -169,6 +172,7 @@ static void hyperv_vmbus_remove(struct hv_device
> *hdev)
>  	struct drm_device *dev = hv_get_drvdata(hdev);
>  	struct hyperv_drm_device *hv = to_hv(dev);
> 
> +	vmbus_set_skip_unload(false);
>  	drm_dev_unplug(dev);
>  	drm_atomic_helper_shutdown(dev);
>  	vmbus_close(hdev->channel);
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> index 7978f8c8108c..d48ca6c23b7c 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
> @@ -212,15 +212,16 @@ static void hyperv_plane_panic_flush(struct
> drm_plane *plane)
>  	struct hyperv_drm_device *hv = to_hv(plane->dev);
>  	struct drm_rect rect;
> 
> -	if (!plane->state || !plane->state->fb)
> -		return;
> +	if (plane->state && plane->state->fb) {
> +		rect.x1 = 0;
> +		rect.y1 = 0;
> +		rect.x2 = plane->state->fb->width;
> +		rect.y2 = plane->state->fb->height;
> 
> -	rect.x1 = 0;
> -	rect.y1 = 0;
> -	rect.x2 = plane->state->fb->width;
> -	rect.y2 = plane->state->fb->height;
> +		hyperv_update_dirt(hv->hdev, &rect);
> +	}
> 
> -	hyperv_update_dirt(hv->hdev, &rect);
> +	vmbus_initiate_unload(true);
>  }
> 
>  static const struct drm_plane_helper_funcs hyperv_plane_helper_funcs = {
> --
> 2.25.1

RE: [EXTERNAL] [PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic

[Long Li]

> 
> Currently, VMBus code initiates a VMBus unload in the panic path so that if a
> kdump kernel is loaded, it can start fresh in setting up its own VMBus connection.
> However, a driver for the VMBus virtual frame buffer may need to flush dirty
> portions of the frame buffer back to the Hyper-V host so that panic information is
> visible in the graphics console. To support such flushing, provide exported
> functions for the frame buffer driver to specify that the VMBus unload should not
> be done by the VMBus driver, and to initiate the VMBus unload itself.
> Together these allow a frame buffer driver to delay the VMBus unload until after
> it has completed the flush.
> 
> Ideally, the VMBus driver could use its own panic-path callback to do the unload
> after all frame buffer drivers have finished. But DRM frame buffer drivers use the
> kmsg dump callback, and there are no callbacks after that in the panic path.
> Hence this somewhat messy approach to properly sequencing the frame buffer
> flush and the VMBus unload.
> 
> Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>

Reviewed-by: Long Li <longli@microsoft.com>


> ---
>  drivers/hv/channel_mgmt.c |  1 +
>  drivers/hv/hyperv_vmbus.h |  1 -
>  drivers/hv/vmbus_drv.c    | 25 ++++++++++++++++++-------
>  include/linux/hyperv.h    |  3 +++
>  4 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index
> 74fed2c073d4..5de83676dbad 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -944,6 +944,7 @@ void vmbus_initiate_unload(bool crash)
>  	else
>  		vmbus_wait_for_unload();
>  }
> +EXPORT_SYMBOL_GPL(vmbus_initiate_unload);
> 
>  static void vmbus_setup_channel_state(struct vmbus_channel *channel,
>  				      struct vmbus_channel_offer_channel *offer)
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index
> cdbc5f5c3215..5d3944fc93ae 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -440,7 +440,6 @@ void hv_vss_deinit(void);  int hv_vss_pre_suspend(void);
> int hv_vss_pre_resume(void);  void hv_vss_onchannelcallback(void *context); -
> void vmbus_initiate_unload(bool crash);
> 
>  static inline void hv_poll_channel(struct vmbus_channel *channel,
>  				   void (*cb)(void *))
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index
> 6785ad63a9cb..97dfa529d250 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -69,19 +69,29 @@ bool vmbus_is_confidential(void)  }
> EXPORT_SYMBOL_GPL(vmbus_is_confidential);
> 
> +static bool skip_vmbus_unload;
> +
> +/*
> + * Allow a VMBus framebuffer driver to specify that in the case of a
> +panic,
> + * it will do the VMbus unload operation once it has flushed any dirty
> + * portions of the framebuffer to the Hyper-V host.
> + */
> +void vmbus_set_skip_unload(bool skip)
> +{
> +	skip_vmbus_unload = skip;
> +}
> +EXPORT_SYMBOL_GPL(vmbus_set_skip_unload);
> +
>  /*
>   * The panic notifier below is responsible solely for unloading the
>   * vmbus connection, which is necessary in a panic event.
> - *
> - * Notice an intrincate relation of this notifier with Hyper-V
> - * framebuffer panic notifier exists - we need vmbus connection alive
> - * there in order to succeed, so we need to order both with each other
> - * [see hvfb_on_panic()] - this is done using notifiers' priorities.
>   */
>  static int hv_panic_vmbus_unload(struct notifier_block *nb, unsigned long val,
>  			      void *args)
>  {
> -	vmbus_initiate_unload(true);
> +	if (!skip_vmbus_unload)
> +		vmbus_initiate_unload(true);
> +
>  	return NOTIFY_DONE;
>  }
>  static struct notifier_block hyperv_panic_vmbus_unload_block = { @@ -2848,7
> +2858,8 @@ static void hv_crash_handler(struct pt_regs *regs)  {
>  	int cpu;
> 
> -	vmbus_initiate_unload(true);
> +	if (!skip_vmbus_unload)
> +		vmbus_initiate_unload(true);
>  	/*
>  	 * In crash handler we can't schedule synic cleanup for all CPUs,
>  	 * doing the cleanup for current CPU only. This should be sufficient diff --
> git a/include/linux/hyperv.h b/include/linux/hyperv.h index
> dfc516c1c719..b0502a336eb3 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1334,6 +1334,9 @@ int vmbus_allocate_mmio(struct resource **new,
> struct hv_device *device_obj,
>  			bool fb_overlap_ok);
>  void vmbus_free_mmio(resource_size_t start, resource_size_t size);
> 
> +void vmbus_initiate_unload(bool crash); void vmbus_set_skip_unload(bool
> +skip);
> +
>  /*
>   * GUID definitions of various offer types - services offered to the guest.
>   */
> --
> 2.25.1