From: Jocelyn Falempe <jfalempe@redhat.com>
To: mhklinux@outlook.com, drawat.floss@gmail.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com, ryasuoka@redhat.com
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/hyperv: During panic do VMBus unload after frame buffer is flushed
Date: Wed, 11 Feb 2026 22:54:11 +0100 [thread overview]
Message-ID: <a5372b72-8dc0-4f2d-ad5c-086f3e75ee81@redhat.com> (raw)
In-Reply-To: <20260209070201.1492-2-mhklinux@outlook.com>
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
next prev parent reply other threads:[~2026-02-11 21:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 7:02 [PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic mhkelley58
2026-02-09 7:02 ` [PATCH 2/2] drm/hyperv: During panic do VMBus unload after frame buffer is flushed mhkelley58
2026-02-11 21:54 ` Jocelyn Falempe [this message]
2026-02-11 23:01 ` mhklkml
2026-02-12 9:49 ` Jocelyn Falempe
2026-02-12 10:10 ` Jocelyn Falempe
2026-02-12 16:30 ` Michael Kelley
2026-03-17 18:43 ` [EXTERNAL] " Long Li
2026-03-17 18:43 ` [EXTERNAL] [PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic Long Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a5372b72-8dc0-4f2d-ad5c-086f3e75ee81@redhat.com \
--to=jfalempe@redhat.com \
--cc=airlied@gmail.com \
--cc=decui@microsoft.com \
--cc=drawat.floss@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mhklinux@outlook.com \
--cc=mripard@kernel.org \
--cc=ryasuoka@redhat.com \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.de \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®