+++ /dev/null
-From cb5dfdad9b774e57874864ac995a0a0ccbbd0a49 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Mon, 19 May 2025 21:01:43 -0700
-Subject: Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests
-
-From: Michael Kelley <mhklinux@outlook.com>
-
-[ Upstream commit 96959283a58d91ae20d025546f00e16f0a555208 ]
-
-The Hyper-V host provides guest VMs with a range of MMIO addresses
-that guest VMBus drivers can use. The VMBus driver in Linux manages
-that MMIO space, and allocates portions to drivers upon request. As
-part of managing that MMIO space in a Generation 2 VM, the VMBus
-driver must reserve the portion of the MMIO space that Hyper-V has
-designated for the synthetic frame buffer, and not allocate this
-space to VMBus drivers other than graphics framebuffer drivers. The
-synthetic frame buffer MMIO area is described by the screen_info data
-structure that is passed to the Linux kernel at boot time, so the
-VMBus driver must access screen_info for Generation 2 VMs. (In
-Generation 1 VMs, the framebuffer MMIO space is communicated to
-the guest via a PCI pseudo-device, and access to screen_info is
-not needed.)
-
-In commit a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
-the VMBus driver's access to screen_info is restricted to when
-CONFIG_SYSFB is enabled. CONFIG_SYSFB is typically enabled in kernels
-built for Hyper-V by virtue of having at least one of CONFIG_FB_EFI,
-CONFIG_FB_VESA, or CONFIG_SYSFB_SIMPLEFB enabled, so the restriction
-doesn't usually affect anything. But it's valid to have none of these
-enabled, in which case CONFIG_SYSFB is not enabled, and the VMBus driver
-is unable to properly reserve the framebuffer MMIO space for graphics
-framebuffer drivers. The framebuffer MMIO space may be assigned to
-some other VMBus driver, with undefined results. As an example, if
-a VM is using a PCI pass-thru NVMe controller to host the OS disk,
-the PCI NVMe controller is probed before any graphics devices, and the
-NVMe controller is assigned a portion of the framebuffer MMIO space.
-Hyper-V reports an error to Linux during the probe, and the OS disk
-fails to get setup. Then Linux fails to boot in the VM.
-
-Fix this by having CONFIG_HYPERV always select SYSFB. Then the
-VMBus driver in a Gen 2 VM can always reserve the MMIO space for the
-graphics framebuffer driver, and prevent the undefined behavior. But
-don't select SYSFB when building for HYPERV_VTL_MODE as VTLs other
-than VTL 0 don't have a framebuffer and aren't subject to the issue.
-Adding SYSFB in such cases is harmless, but would increase the image
-size for no purpose.
-
-Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
-Signed-off-by: Michael Kelley <mhklinux@outlook.com>
-Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
-Link: https://lore.kernel.org/stable/20250520040143.6964-1-mhklinux%40outlook.com
-Link: https://lore.kernel.org/r/20250520040143.6964-1-mhklinux@outlook.com
-Signed-off-by: Wei Liu <wei.liu@kernel.org>
-Message-ID: <20250520040143.6964-1-mhklinux@outlook.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/hv/Kconfig | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
-index 862c47b191afe..f492693b26734 100644
---- a/drivers/hv/Kconfig
-+++ b/drivers/hv/Kconfig
-@@ -9,6 +9,7 @@ config HYPERV
- select PARAVIRT
- select X86_HV_CALLBACK_VECTOR if X86
- select OF_EARLY_FLATTREE if OF
-+ select SYSFB if !HYPERV_VTL_MODE
- help
- Select this option to run Linux as a Hyper-V client operating
- system.
---
-2.39.5
-
mfd-exynos-lpass-fix-an-error-handling-path-in-exyno.patch
mfd-exynos-lpass-avoid-calling-exynos_lpass_disable-.patch
mfd-stmpe-spi-correct-the-name-used-in-module_device.patch
-drivers-hv-always-select-config_sysfb-for-hyper-v-gu.patch
perf-tests-switch-tracking-fix-timestamp-comparison.patch
mailbox-imx-fix-txdb_v2-sending.patch
mailbox-mtk-cmdq-refine-gce_gctl_value-setting.patch
+++ /dev/null
-From 9766859ee9884c35dde0411df167a06452fee3ce Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Mon, 19 May 2025 21:01:43 -0700
-Subject: Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests
-
-From: Michael Kelley <mhklinux@outlook.com>
-
-[ Upstream commit 96959283a58d91ae20d025546f00e16f0a555208 ]
-
-The Hyper-V host provides guest VMs with a range of MMIO addresses
-that guest VMBus drivers can use. The VMBus driver in Linux manages
-that MMIO space, and allocates portions to drivers upon request. As
-part of managing that MMIO space in a Generation 2 VM, the VMBus
-driver must reserve the portion of the MMIO space that Hyper-V has
-designated for the synthetic frame buffer, and not allocate this
-space to VMBus drivers other than graphics framebuffer drivers. The
-synthetic frame buffer MMIO area is described by the screen_info data
-structure that is passed to the Linux kernel at boot time, so the
-VMBus driver must access screen_info for Generation 2 VMs. (In
-Generation 1 VMs, the framebuffer MMIO space is communicated to
-the guest via a PCI pseudo-device, and access to screen_info is
-not needed.)
-
-In commit a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
-the VMBus driver's access to screen_info is restricted to when
-CONFIG_SYSFB is enabled. CONFIG_SYSFB is typically enabled in kernels
-built for Hyper-V by virtue of having at least one of CONFIG_FB_EFI,
-CONFIG_FB_VESA, or CONFIG_SYSFB_SIMPLEFB enabled, so the restriction
-doesn't usually affect anything. But it's valid to have none of these
-enabled, in which case CONFIG_SYSFB is not enabled, and the VMBus driver
-is unable to properly reserve the framebuffer MMIO space for graphics
-framebuffer drivers. The framebuffer MMIO space may be assigned to
-some other VMBus driver, with undefined results. As an example, if
-a VM is using a PCI pass-thru NVMe controller to host the OS disk,
-the PCI NVMe controller is probed before any graphics devices, and the
-NVMe controller is assigned a portion of the framebuffer MMIO space.
-Hyper-V reports an error to Linux during the probe, and the OS disk
-fails to get setup. Then Linux fails to boot in the VM.
-
-Fix this by having CONFIG_HYPERV always select SYSFB. Then the
-VMBus driver in a Gen 2 VM can always reserve the MMIO space for the
-graphics framebuffer driver, and prevent the undefined behavior. But
-don't select SYSFB when building for HYPERV_VTL_MODE as VTLs other
-than VTL 0 don't have a framebuffer and aren't subject to the issue.
-Adding SYSFB in such cases is harmless, but would increase the image
-size for no purpose.
-
-Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
-Signed-off-by: Michael Kelley <mhklinux@outlook.com>
-Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
-Link: https://lore.kernel.org/stable/20250520040143.6964-1-mhklinux%40outlook.com
-Link: https://lore.kernel.org/r/20250520040143.6964-1-mhklinux@outlook.com
-Signed-off-by: Wei Liu <wei.liu@kernel.org>
-Message-ID: <20250520040143.6964-1-mhklinux@outlook.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/hv/Kconfig | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
-index 6c1416167bd2e..724fc08a73e70 100644
---- a/drivers/hv/Kconfig
-+++ b/drivers/hv/Kconfig
-@@ -9,6 +9,7 @@ config HYPERV
- select PARAVIRT
- select X86_HV_CALLBACK_VECTOR if X86
- select OF_EARLY_FLATTREE if OF
-+ select SYSFB if !HYPERV_VTL_MODE
- help
- Select this option to run Linux as a Hyper-V client operating
- system.
---
-2.39.5
-
mfd-exynos-lpass-fix-another-error-handling-path-in-.patch
mfd-stmpe-spi-correct-the-name-used-in-module_device.patch
netfs-fix-undifferentiation-of-dio-reads-from-unbuff.patch
-drivers-hv-always-select-config_sysfb-for-hyper-v-gu.patch
perf-tests-switch-tracking-fix-timestamp-comparison.patch
mailbox-mchp-ipc-sbi-fix-compile_test-build-error.patch
mailbox-imx-fix-txdb_v2-sending.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
