mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-09-04 20:19:47 +08:00
96959283a5
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 commita07b50d80a("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:a07b50d80a("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>
77 lines
2.4 KiB
Plaintext
77 lines
2.4 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
menu "Microsoft Hyper-V guest support"
|
|
|
|
config HYPERV
|
|
tristate "Microsoft Hyper-V client drivers"
|
|
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|
|
|| (ARM64 && !CPU_BIG_ENDIAN)
|
|
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.
|
|
|
|
config HYPERV_VTL_MODE
|
|
bool "Enable Linux to boot in VTL context"
|
|
depends on (X86_64 || ARM64) && HYPERV
|
|
depends on SMP
|
|
default n
|
|
help
|
|
Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
|
|
enlightenments offered to host and guest partitions which enables
|
|
the creation and management of new security boundaries within
|
|
operating system software.
|
|
|
|
VSM achieves and maintains isolation through Virtual Trust Levels
|
|
(VTLs). Virtual Trust Levels are hierarchical, with higher levels
|
|
being more privileged than lower levels. VTL0 is the least privileged
|
|
level, and currently only other level supported is VTL2.
|
|
|
|
Select this option to build a Linux kernel to run at a VTL other than
|
|
the normal VTL0, which currently is only VTL2. This option
|
|
initializes the kernel to run in VTL2, and adds the ability to boot
|
|
secondary CPUs directly into 64-bit context as required for VTLs other
|
|
than 0. A kernel built with this option must run at VTL2, and will
|
|
not run as a normal guest.
|
|
|
|
If unsure, say N
|
|
|
|
config HYPERV_TIMER
|
|
def_bool HYPERV && X86
|
|
|
|
config HYPERV_UTILS
|
|
tristate "Microsoft Hyper-V Utilities driver"
|
|
depends on HYPERV && CONNECTOR && NLS
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
|
help
|
|
Select this option to enable the Hyper-V Utilities.
|
|
|
|
config HYPERV_BALLOON
|
|
tristate "Microsoft Hyper-V Balloon driver"
|
|
depends on HYPERV
|
|
select PAGE_REPORTING
|
|
help
|
|
Select this option to enable Hyper-V Balloon driver.
|
|
|
|
config MSHV_ROOT
|
|
tristate "Microsoft Hyper-V root partition support"
|
|
depends on HYPERV && (X86_64 || ARM64)
|
|
depends on !HYPERV_VTL_MODE
|
|
# The hypervisor interface operates on 4k pages. Enforcing it here
|
|
# simplifies many assumptions in the root partition code.
|
|
# e.g. When withdrawing memory, the hypervisor gives back 4k pages in
|
|
# no particular order, making it impossible to reassemble larger pages
|
|
depends on PAGE_SIZE_4KB
|
|
select EVENTFD
|
|
default n
|
|
help
|
|
Select this option to enable support for booting and running as root
|
|
partition on Microsoft Hyper-V.
|
|
|
|
If unsure, say N.
|
|
|
|
endmenu
|