mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®