From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 413EC2A1BA for ; Thu, 12 Feb 2026 09:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770889804; cv=none; b=gxY+UumlbPNg1Is5Era5Agthcl/NNyO/0mD0NvsDA6ThvSsKjwf7f5TI8aMkgJAHlTioFVUGDn6oLy6L7aE4fP47YsDmRoJVPnUav2gNlOXrx3hU+OusYgyycrkYoLOc4VlZyLjF7uGyMosd/UkJhsxYLCkfARB2ti6phbDKT2s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770889804; c=relaxed/simple; bh=ssiBpGwudSOhWWpXd6ltuV0trtgpSjINF3dITy6pg0s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=goRogSRc37fNW6WK3xNFqlFqGGhrb/P2WrCw+h58OjY4ttZavo3EQ7LwWOpSu0ztMYzIF383KnJPx1CwGGGvpDrK89g/yR03Llci/8iurI5K4o5uDwTiV2Pmde49O6KG16CPl8rxnPG9jXaToQpwh3JqOn/YzL9l901ex0RrR2c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=CRCnp2Uw; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=UM1tzJ7u; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CRCnp2Uw"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="UM1tzJ7u" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770889802; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7izo/A5Ul08EXM2WpJ9NM5vTC0yA5lFDEQbyiP4NFcY=; b=CRCnp2UwTvVzBCMIWlVfd4+IXB3P8x9g5GNV+WL6SeueerGzvkGLz/9sslIX0u5YeaN803 sKQMHYZ0xP+8mYmMi9QzZiuuK+kdHxuJvRtzNCB17Mxuxbx368ETnNcsQoSemHHjQIxvzV V6yiKGl1XJ3E22Wg4gC8dP66IKjTO8M= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-512-cwhP8ZvkP2mBg0pD14R30Q-1; Thu, 12 Feb 2026 04:50:00 -0500 X-MC-Unique: cwhP8ZvkP2mBg0pD14R30Q-1 X-Mimecast-MFC-AGG-ID: cwhP8ZvkP2mBg0pD14R30Q_1770889800 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48336b182ebso35252585e9.3 for ; Thu, 12 Feb 2026 01:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770889799; x=1771494599; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7izo/A5Ul08EXM2WpJ9NM5vTC0yA5lFDEQbyiP4NFcY=; b=UM1tzJ7u887hU+Bo0jjFMc6ZolvP1/wL5b1+c4dpfRfi5cvyD2swHCSKQCQPbQSR0J li8uh3p/z5tLWsEz+tIr3j6xPlt+rFU8uvnAvq5gJjNddkGXLLaHt7BFBDc3z3UDWalC G9bcoJ5t+/pZroQHSPznmWPkdRLaH3GXjq1o17LiHeBto7wwy0Y5D4wlomqF8uv7OLpf sE0jnRptuDbtMmXtHR+h0/2Jd2z8ZtDicQrQHTwwS3WpYMnrWCBurmjB6Lhvs+iePzFL PkCiwqn0603bq+S68IsNBCthG30Y0al64X0cdp17vPlM8u6KJGniye3o1BtC3vwksFgI pGIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770889799; x=1771494599; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7izo/A5Ul08EXM2WpJ9NM5vTC0yA5lFDEQbyiP4NFcY=; b=vmsJE/0FwdXNbfqjeaNmuut0REeA3a8p6+38YnSSiPyagcIjyCBe2aYbvANkLKvAk0 Cuv/WUsADAQbPN+qqiu2qVe/qHqa9teLchLBb4kZegx0v3HT96sXXnZms0AytZ/+5X0C CRJHN4T97nwupp1n0dSO8ef14R9S92Q+JlIdDguHUJrfVKvAK2v47HpQDI+Tq6LAmknq NCbVbwsVePgI8nuSD4eGWXbhZmXbgRJMmce9qOppK/cmUcpvZNCrN8aKiEqRmXQRt+2e 8dV+qbyNw0fcDc18Khw5R9tLjQHpxGGEyfm3mMN5jbaq13jyJr8VVwT4zvQVPgqUAfPW cxtw== X-Forwarded-Encrypted: i=1; AJvYcCWvSg90dKIUU0ePNxF9cE7dbybc6Q/TZhSQZ+P+ZV5hwkV5C7WaaABA+krVnyGT7aRiavXIMlnJbBCquv4=@vger.kernel.org X-Gm-Message-State: AOJu0YyL1jbDVDRMFipQBMkr8j8vmd3HXCYVAFktXeGgjcYsURzcP4M5 cVfkppmWblwvjffPtMKh+ukFpB3Je/ggSEoLu5RaPRYJimYWQ6WRLMih7tcRNPHZz0o9w7oJU34 V6ftatlAUgAlsu5lUXJi5+mtu6asPb5/ogEX5q/mc5cFpimb2nN/G9eOWCuZ6niD3ZQ== X-Gm-Gg: AZuq6aJ0Xu/gMxp4NNs6Pb38Ogq1U8NYEa3EhZ+5WWLQgUPCtQZebr3tN+5a82TC59m Tmx0DLNk2hjO6M5rP/KqTMYCnnk7R5w0HBp4Ktu2GK6iVLDkz6FUwQpPiqU1/8Ld5bl4kDpUuCX xxoldWXRSm4A2oineL2CmjdrEHJoE0ul1KDNiLz0au5q/MldE32+0sgycfaqaEORdTNVvPvdFPw xaVX73REVL6iMKSqb3unHb5WX5mP/amNWYoq8hC70Uh4v7Bt3gMmNpbi2Yt8cI9G0s/P1PuGv9i DQYitK+vkkJ2wSC3v/Glg/Gwv9JOWQF8Mzqj0Za8wiw1XcWnaXfTdHJn1M6VJLzk24lEJ1B7vdV mykVjCMdwpVfxiX8mdg7UzQ5sIAQH2wtGYVkQd/VAWBdoikQtZ+TgyMAC3fQVow== X-Received: by 2002:a05:600c:c08f:b0:483:6e32:50d4 with SMTP id 5b1f17b1804b1-4836e3250ddmr2220525e9.18.1770889799513; Thu, 12 Feb 2026 01:49:59 -0800 (PST) X-Received: by 2002:a05:600c:c08f:b0:483:6e32:50d4 with SMTP id 5b1f17b1804b1-4836e3250ddmr2220055e9.18.1770889799021; Thu, 12 Feb 2026 01:49:59 -0800 (PST) Received: from ?IPV6:2a01:e0a:c:37e0:8998:e0cf:68cc:1b62? ([2a01:e0a:c:37e0:8998:e0cf:68cc:1b62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4836aa0847asm29634535e9.3.2026.02.12.01.49.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Feb 2026 01:49:58 -0800 (PST) Message-ID: Date: Thu, 12 Feb 2026 10:49:54 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] drm/hyperv: During panic do VMBus unload after frame buffer is flushed To: mhklkml@zohomail.com, 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 References: <20260209070201.1492-1-mhklinux@outlook.com> <20260209070201.1492-2-mhklinux@outlook.com> <002601dc9baa$517d8b40$f478a1c0$@zohomail.com> Content-Language: en-US, fr From: Jocelyn Falempe In-Reply-To: <002601dc9baa$517d8b40$f478a1c0$@zohomail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/02/2026 00:01, mhklkml@zohomail.com wrote: > From: Jocelyn Falempe Sent: Wednesday, February 11, 2026 1:54 PM >> >> On 09/02/2026 08:02, mhkelley58@gmail.com wrote: >>> From: Michael Kelley >>> >>> 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 >> >> 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 >>> --- >>> 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; >