From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f196.google.com (mail-dy1-f196.google.com [74.125.82.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B1911D6BB for ; Mon, 9 Feb 2026 07:02:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.196 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770620546; cv=none; b=AaRnwKA7+6rXDVSQUyJBjWndD6doTCklK1W1jfuMQOA7MIw0ty5ONDz9JlqtiJ0BiDl943aT06Cl5d8RGO2u/SA2Ozt9RW0DxjUf6XGFBBEChgf9XzCMs3G18HJ4MQ6kLnfphurzH8Lx1YGjK5bGexktPUj4dWEOuDrU8EdvhaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770620546; c=relaxed/simple; bh=IOtBl8MKHrgNuRhXhPZVlOsJtxt9RN8qVWDNq6+9ARQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=cp1M1h0Z87Oo0FoDQB6BI1/n5ANIHI5vln+kLKX96NxckI/k0qUC+IG54mPHfhDjPL+A7aP3FoD1KuZtLlUXmuZoEJaXG7jdicV+oFs415AXAzCf5FgNBNIVZIs4Ax/Fv6Vqtu+Q5ofbrsOAFF3JR+Z5/+BTEc9eiy+CsVVpKDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=i4L4Gdck; arc=none smtp.client-ip=74.125.82.196 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i4L4Gdck" Received: by mail-dy1-f196.google.com with SMTP id 5a478bee46e88-2b8675d4f93so1243021eec.0 for ; Sun, 08 Feb 2026 23:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770620546; x=1771225346; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=QTQsukcOvGgA1IOwGu0V6U/4Hj9O7nggXaNLrVfcPCU=; b=i4L4Gdck2pRYyWTfLd+BwWzgMD2mp3jybKtsiMskNmG3ALh/dTzi9aRyKkaLvO94Ab 375+tTtGA9afCyIz9YUNE4e6FkVJhjjItpsLd1NK7Z4pEfRrPWACT8/k7HHbfZUg1GpK LfTAyA00vEigr4C3otMrmZJEDI+X4yRU/1fn//SwipRqYbqc11yREZzBGornsvWUqKDf NQvPrV9zF2JswziCuDIy1U2u6hXm3MgJgveBYecahRN3FPdJzn/A82JvXw6Y3H9N7w6C 2rsD45f/kL6no+wNwCsPhsOyUqafaoJr2sSLuCtsQdzUjO0AMVbQbDht9IXsr4vAPreg g3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770620546; x=1771225346; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=QTQsukcOvGgA1IOwGu0V6U/4Hj9O7nggXaNLrVfcPCU=; b=tg+RVdxCWuQLZc8NOPsbsU5H0Bl01mMar0olTLKCu9Ir73/pfgnyCJ4+DJgYWXjl5F rec+deXd5x71U0fPH2ih8gJzkc28Q/pfeJOIcZfB/huaseZ2Dimxds3KFmtqe6eOCRlo 0WDYG6iAt8sLEkIzvEbuJGI6InN5U9K4PmadEIccIXVSt4Y3Kd2R0pns15XYwGcyBcx6 JAY/BdDQz7EhESCNpCRCDFGsBj2r+JyWHVIZyw2lfv8e3yfFMvfKThHZD5sDLGXoSCzZ HusHuWvPmhL8jxH0Abum67kuBH9TxaM8ar5PqZLvU+w6T/nnKJAluaDCqk7Stw4L7ay7 XIkA== X-Forwarded-Encrypted: i=1; AJvYcCUbrYhMd+hnA3X81+2kJRTLD/aEJ8oYWuyPp/biaNmdmVR1sqq+DoshkjkwmSCOthWGdMZP1l8M/zM6Ms4=@vger.kernel.org X-Gm-Message-State: AOJu0YyIJ4MbJpohDhG9OJnKf/J1RZrguQoE1mwBMekVjsQK3Hwq7qDF JuloN7SdVwOxCwSBKk/jvSz5quBvSdnEMBMXuPYyOWOy/DkE8LW5bjwt X-Gm-Gg: AZuq6aIaRqi9hRo7GegXXahntf4Czr+yMAPjQieBQWOE50/+HmfAr0CAh+SsjMB/E7E +dKnuDAq/VR3ycsuJTlGoYvb4uFL8GGyzZJrFtkjFiBeys58VEedjjCJLOfuTdOyPwRoijKaWqk c1es7NcfNC1hM9eAJTd+haRw2/nqIu5WZlASbzQpqjwFr1sulTrLJgSGBEQXpPe07wFWVFCDGUJ fTXJ7Y8KODV50m3xm/2UbFrYAy5Hk/g4PNRc8tyy47UIxSFFFlvRsAqYSqLu5SQ/J01z4yTlnd0 r8ND4nEDroKvGQ5n/GlV0yxlfB1E4ItIKorPFP9zDCF/p8+6Eg1CfvB2RQlX5z7xn88TuuZT1kd MdPj9lIhBhQDhc30vguUy2EZ25K28j+0OfImGuH3K6pV2HK06pual38rqEDkdXDH0ov7jkMXM/O G8nA/8boY+/cBi5rx847B3TmjGF2ignw== X-Received: by 2002:a05:7301:38a6:b0:2b8:31e5:918 with SMTP id 5a478bee46e88-2b856a4c311mr3244690eec.37.1770620545505; Sun, 08 Feb 2026 23:02:25 -0800 (PST) Received: from mhkubun.search.charter.net ([66.91.163.55]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12706faa047sm6966305c88.14.2026.02.08.23.02.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Feb 2026 23:02:25 -0800 (PST) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: 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, jfalempe@redhat.com Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 1/2] Drivers: hv: vmbus: Provide option to skip VMBus unload on panic Date: Sun, 8 Feb 2026 23:02:00 -0800 Message-Id: <20260209070201.1492-1-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Michael Kelley 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 --- 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