[PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Mukesh Rathor]

At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
hv_common.c that is needed for the drivers. Moreover, vmbus driver is
built if CONFIG_HYPER is set, either loadable or builtin.

This is not a good approach. CONFIG_HYPERV is really an umbrella config that
encompasses builtin code and various other things and not a dedicated config
option for VMBUS. Vmbus should really have a config option just like
CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
to build VMBUS driver and make that distinction explicit. With that
CONFIG_HYPERV could be changed to bool.

For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
but once merges are mostly done, that and some others should be moved to
virt/hyperv directory.

Mukesh Rathor (2):
  hyper-v: Add CONFIG_HYPERV_VMBUS option
  hyper-v: Make CONFIG_HYPERV bool

 drivers/Makefile               |  2 +-
 drivers/gpu/drm/Kconfig        |  2 +-
 drivers/hid/Kconfig            |  2 +-
 drivers/hv/Kconfig             | 14 ++++++++++----
 drivers/hv/Makefile            |  4 ++--
 drivers/input/serio/Kconfig    |  4 ++--
 drivers/net/hyperv/Kconfig     |  2 +-
 drivers/pci/Kconfig            |  2 +-
 drivers/scsi/Kconfig           |  2 +-
 drivers/uio/Kconfig            |  2 +-
 drivers/video/fbdev/Kconfig    |  2 +-
 include/asm-generic/mshyperv.h |  8 +++++---
 net/vmw_vsock/Kconfig          |  2 +-
 13 files changed, 28 insertions(+), 20 deletions(-)

-- 
2.36.1.vfs.0.0

[PATCH V0 1/2] hyper-v: Add CONFIG_HYPERV_VMBUS option

[Mukesh Rathor]

Somehow vmbus driver is hinged on CONFIG_HYPERV. It appears this is initial
code that did not get addressed when the scope of CONFIG_HYPERV went beyond
vmbus. This commit creates a fine grained HYPERV_VMBUS option and updates
drivers that depend on VMBUS.

Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
 drivers/gpu/drm/Kconfig        |  2 +-
 drivers/hid/Kconfig            |  2 +-
 drivers/hv/Kconfig             | 12 +++++++++---
 drivers/hv/Makefile            |  2 +-
 drivers/input/serio/Kconfig    |  4 ++--
 drivers/net/hyperv/Kconfig     |  2 +-
 drivers/pci/Kconfig            |  2 +-
 drivers/scsi/Kconfig           |  2 +-
 drivers/uio/Kconfig            |  2 +-
 drivers/video/fbdev/Kconfig    |  2 +-
 include/asm-generic/mshyperv.h |  8 +++++---
 net/vmw_vsock/Kconfig          |  2 +-
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
 
 config DRM_HYPERV
 	tristate "DRM Support for Hyper-V synthetic video device"
-	depends on DRM && PCI && HYPERV
+	depends on DRM && PCI && HYPERV_VMBUS
 	select DRM_CLIENT_SELECTION
 	select DRM_KMS_HELPER
 	select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
 
 config HID_HYPERV_MOUSE
 	tristate "Microsoft Hyper-V mouse driver"
-	depends on HYPERV
+	depends on HYPERV_VMBUS
 	help
 	Select this option to enable the Hyper-V mouse driver.
 
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 2e8df09db599..08c4ed005137 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -44,18 +44,24 @@ config HYPERV_TIMER
 
 config HYPERV_UTILS
 	tristate "Microsoft Hyper-V Utilities driver"
-	depends on HYPERV && CONNECTOR && NLS
+	depends on HYPERV_VMBUS && 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
+	depends on HYPERV_VMBUS
 	select PAGE_REPORTING
 	help
 	  Select this option to enable Hyper-V Balloon driver.
 
+config HYPERV_VMBUS
+	tristate "Microsoft Hyper-V Vmbus driver"
+	depends on HYPERV
+	help
+	  Select this option to enable Hyper-V Vmbus driver.
+
 config MSHV_ROOT
 	tristate "Microsoft Hyper-V root partition support"
 	depends on HYPERV && (X86_64 || ARM64)
@@ -75,7 +81,7 @@ config MSHV_ROOT
 
 config MSHV_VTL
 	tristate "Microsoft Hyper-V VTL driver"
-	depends on X86_64 && HYPERV_VTL_MODE
+	depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
 	# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
 	# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
 	# specially with large memory requirements.
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index c53a0df746b7..050517756a82 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS)	+= hv_vmbus.o
 obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
 obj-$(CONFIG_HYPERV_BALLOON)	+= hv_balloon.o
 obj-$(CONFIG_MSHV_ROOT)		+= mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
 
 config HYPERV_KEYBOARD
 	tristate "Microsoft Synthetic Keyboard driver"
-	depends on HYPERV
-	default HYPERV
+	depends on HYPERV_VMBUS
+	default HYPERV_VMBUS
 	help
 	  Select this option to enable the Hyper-V Keyboard driver.
 
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config HYPERV_NET
 	tristate "Microsoft Hyper-V virtual network driver"
-	depends on HYPERV
+	depends on HYPERV_VMBUS
 	select UCS2_STRING
 	select NLS
 	help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
 
 config PCI_HYPERV
 	tristate "Hyper-V PCI Frontend"
-	depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+	depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
 	select PCI_HYPERV_INTERFACE
 	select IRQ_MSI_LIB
 	help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
 
 config HYPERV_STORAGE
 	tristate "Microsoft Hyper-V virtual storage driver"
-	depends on SCSI && HYPERV
+	depends on SCSI && HYPERV_VMBUS
 	depends on m || SCSI_FC_ATTRS != m
 	default HYPERV
 	help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
 
 config UIO_HV_GENERIC
 	tristate "Generic driver for Hyper-V VMBus"
-	depends on HYPERV
+	depends on HYPERV_VMBUS
 	help
 	  Generic driver that you can bind, dynamically, to any
 	  Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
 
 config FB_HYPERV
 	tristate "Microsoft Hyper-V Synthetic Video support"
-	depends on FB && HYPERV
+	depends on FB && HYPERV_VMBUS
 	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
 	select FB_IOMEM_HELPERS_DEFERRED
 	help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 1d2ad1304ad4..66c58c91b530 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
 
 void __init hv_mark_resources(void);
 
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
 /* Free the message slot and signal end-of-message if required */
 static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
 {
@@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
 	}
 }
 
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
 int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
 
 void hv_setup_vmbus_handler(void (*handler)(void));
@@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
 void hv_remove_crash_handler(void);
 void hv_setup_mshv_handler(void (*handler)(void));
 
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
 #if IS_ENABLED(CONFIG_HYPERV)
 /*
  * Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
 
 config HYPERV_VSOCKETS
 	tristate "Hyper-V transport for Virtual Sockets"
-	depends on VSOCKETS && HYPERV
+	depends on VSOCKETS && HYPERV_VMBUS
 	help
 	  This module implements a Hyper-V transport for Virtual Sockets.
 
-- 
2.36.1.vfs.0.0

Re: [PATCH V0 1/2] hyper-v: Add CONFIG_HYPERV_VMBUS option

[Nuno Das Neves]

On 8/27/2025 5:59 PM, Mukesh Rathor wrote:
> Somehow vmbus driver is hinged on CONFIG_HYPERV. It appears this is initial
> code that did not get addressed when the scope of CONFIG_HYPERV went beyond
> vmbus. This commit creates a fine grained HYPERV_VMBUS option and updates
> drivers that depend on VMBUS.
> 

The commit message can be improved. The docs are helpful here:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes

In particular, some clearer reasons for the change.
e.g.
- CONFIG_HYPERV encompasses too much right now. It's not always clear what
  depends on builtin hyperv code and what depends on vmbus.

- Since there is so much builtin hyperv code, building CONFIG_HYPERV as a
  module doesn't make intuitive sense. Building vmbus support as a module does.

- There are actually some real scenarios someone may want to compile with
  CONFIG_HYPERV but without vmbus, like baremetal root partition.

FWIW I think it's a good idea, interested to hear what others think.

Nuno

> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
>  drivers/gpu/drm/Kconfig        |  2 +-
>  drivers/hid/Kconfig            |  2 +-
>  drivers/hv/Kconfig             | 12 +++++++++---
>  drivers/hv/Makefile            |  2 +-
>  drivers/input/serio/Kconfig    |  4 ++--
>  drivers/net/hyperv/Kconfig     |  2 +-
>  drivers/pci/Kconfig            |  2 +-
>  drivers/scsi/Kconfig           |  2 +-
>  drivers/uio/Kconfig            |  2 +-
>  drivers/video/fbdev/Kconfig    |  2 +-
>  include/asm-generic/mshyperv.h |  8 +++++---
>  net/vmw_vsock/Kconfig          |  2 +-
>  12 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f7ea8e895c0c..58f34da061c6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
>  
>  config DRM_HYPERV
>  	tristate "DRM Support for Hyper-V synthetic video device"
> -	depends on DRM && PCI && HYPERV
> +	depends on DRM && PCI && HYPERV_VMBUS
>  	select DRM_CLIENT_SELECTION
>  	select DRM_KMS_HELPER
>  	select DRM_GEM_SHMEM_HELPER
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a57901203aeb..fe3dc8c0db99 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1162,7 +1162,7 @@ config GREENASIA_FF
>  
>  config HID_HYPERV_MOUSE
>  	tristate "Microsoft Hyper-V mouse driver"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	help
>  	Select this option to enable the Hyper-V mouse driver.
>  
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 2e8df09db599..08c4ed005137 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -44,18 +44,24 @@ config HYPERV_TIMER
>  
>  config HYPERV_UTILS
>  	tristate "Microsoft Hyper-V Utilities driver"
> -	depends on HYPERV && CONNECTOR && NLS
> +	depends on HYPERV_VMBUS && 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
> +	depends on HYPERV_VMBUS
>  	select PAGE_REPORTING
>  	help
>  	  Select this option to enable Hyper-V Balloon driver.
>  
> +config HYPERV_VMBUS
> +	tristate "Microsoft Hyper-V Vmbus driver"
> +	depends on HYPERV
> +	help
> +	  Select this option to enable Hyper-V Vmbus driver.
> +
>  config MSHV_ROOT
>  	tristate "Microsoft Hyper-V root partition support"
>  	depends on HYPERV && (X86_64 || ARM64)
> @@ -75,7 +81,7 @@ config MSHV_ROOT
>  
>  config MSHV_VTL
>  	tristate "Microsoft Hyper-V VTL driver"
> -	depends on X86_64 && HYPERV_VTL_MODE
> +	depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
>  	# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
>  	# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
>  	# specially with large memory requirements.
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index c53a0df746b7..050517756a82 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
> +obj-$(CONFIG_HYPERV_VMBUS)	+= hv_vmbus.o
>  obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
>  obj-$(CONFIG_HYPERV_BALLOON)	+= hv_balloon.o
>  obj-$(CONFIG_MSHV_ROOT)		+= mshv_root.o
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 17edc1597446..c7ef347a4dff 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
>  
>  config HYPERV_KEYBOARD
>  	tristate "Microsoft Synthetic Keyboard driver"
> -	depends on HYPERV
> -	default HYPERV
> +	depends on HYPERV_VMBUS
> +	default HYPERV_VMBUS
>  	help
>  	  Select this option to enable the Hyper-V Keyboard driver.
>  
> diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
> index c8cbd85adcf9..982964c1a9fb 100644
> --- a/drivers/net/hyperv/Kconfig
> +++ b/drivers/net/hyperv/Kconfig
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config HYPERV_NET
>  	tristate "Microsoft Hyper-V virtual network driver"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	select UCS2_STRING
>  	select NLS
>  	help
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9a249c65aedc..7065a8e5f9b1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -221,7 +221,7 @@ config PCI_LABEL
>  
>  config PCI_HYPERV
>  	tristate "Hyper-V PCI Frontend"
> -	depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
> +	depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
>  	select PCI_HYPERV_INTERFACE
>  	select IRQ_MSI_LIB
>  	help
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 5522310bab8d..19d0884479a2 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
>  
>  config HYPERV_STORAGE
>  	tristate "Microsoft Hyper-V virtual storage driver"
> -	depends on SCSI && HYPERV
> +	depends on SCSI && HYPERV_VMBUS
>  	depends on m || SCSI_FC_ATTRS != m
>  	default HYPERV
>  	help
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index b060dcd7c635..6f86a61231e6 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -140,7 +140,7 @@ config UIO_MF624
>  
>  config UIO_HV_GENERIC
>  	tristate "Generic driver for Hyper-V VMBus"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	help
>  	  Generic driver that you can bind, dynamically, to any
>  	  Hyper-V VMBus device. It is useful to provide direct access
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c21484d15f0c..72c63eaeb983 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1774,7 +1774,7 @@ config FB_BROADSHEET
>  
>  config FB_HYPERV
>  	tristate "Microsoft Hyper-V Synthetic Video support"
> -	depends on FB && HYPERV
> +	depends on FB && HYPERV_VMBUS
>  	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
>  	select FB_IOMEM_HELPERS_DEFERRED
>  	help
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index 1d2ad1304ad4..66c58c91b530 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
>  
>  void __init hv_mark_resources(void);
>  
> +#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
>  /* Free the message slot and signal end-of-message if required */
>  static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>  {
> @@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>  	}
>  }
>  
> +extern int vmbus_interrupt;
> +extern int vmbus_irq;
> +#endif /* CONFIG_HYPERV_VMBUS */
> +
>  int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>  
>  void hv_setup_vmbus_handler(void (*handler)(void));
> @@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
>  void hv_remove_crash_handler(void);
>  void hv_setup_mshv_handler(void (*handler)(void));
>  
> -extern int vmbus_interrupt;
> -extern int vmbus_irq;
> -
>  #if IS_ENABLED(CONFIG_HYPERV)
>  /*
>   * Hypervisor's notion of virtual processor ID is different from
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index 56356d2980c8..8e803c4828c4 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
>  
>  config HYPERV_VSOCKETS
>  	tristate "Hyper-V transport for Virtual Sockets"
> -	depends on VSOCKETS && HYPERV
> +	depends on VSOCKETS && HYPERV_VMBUS
>  	help
>  	  This module implements a Hyper-V transport for Virtual Sockets.
>  

Re: [PATCH V0 1/2] hyper-v: Add CONFIG_HYPERV_VMBUS option

[Mukesh R]

On 8/28/25 17:29, Nuno Das Neves wrote:
> On 8/27/2025 5:59 PM, Mukesh Rathor wrote:
>> Somehow vmbus driver is hinged on CONFIG_HYPERV. It appears this is initial
>> code that did not get addressed when the scope of CONFIG_HYPERV went beyond
>> vmbus. This commit creates a fine grained HYPERV_VMBUS option and updates
>> drivers that depend on VMBUS.
>>
> 
> The commit message can be improved. The docs are helpful here:
> https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
> 
> In particular, some clearer reasons for the change.
> e.g.
> - CONFIG_HYPERV encompasses too much right now. It's not always clear what
>   depends on builtin hyperv code and what depends on vmbus.
> 
> - Since there is so much builtin hyperv code, building CONFIG_HYPERV as a
>   module doesn't make intuitive sense. Building vmbus support as a module does.
> 
> - There are actually some real scenarios someone may want to compile with
>   CONFIG_HYPERV but without vmbus, like baremetal root partition.
> 
> FWIW I think it's a good idea, interested to hear what others think.

Sorry, you had mentioned it and I expanded the cover letter and forgot the
commit message here. You said it better than I could above, so I can just use
that in V1 next week if no other comments.

Thanks,
-Mukesh


> Nuno
> 
>> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> ---
>>  drivers/gpu/drm/Kconfig        |  2 +-
>>  drivers/hid/Kconfig            |  2 +-
>>  drivers/hv/Kconfig             | 12 +++++++++---
>>  drivers/hv/Makefile            |  2 +-
>>  drivers/input/serio/Kconfig    |  4 ++--
>>  drivers/net/hyperv/Kconfig     |  2 +-
>>  drivers/pci/Kconfig            |  2 +-
>>  drivers/scsi/Kconfig           |  2 +-
>>  drivers/uio/Kconfig            |  2 +-
>>  drivers/video/fbdev/Kconfig    |  2 +-
>>  include/asm-generic/mshyperv.h |  8 +++++---
>>  net/vmw_vsock/Kconfig          |  2 +-
>>  12 files changed, 25 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index f7ea8e895c0c..58f34da061c6 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
>>  
>>  config DRM_HYPERV
>>  	tristate "DRM Support for Hyper-V synthetic video device"
>> -	depends on DRM && PCI && HYPERV
>> +	depends on DRM && PCI && HYPERV_VMBUS
>>  	select DRM_CLIENT_SELECTION
>>  	select DRM_KMS_HELPER
>>  	select DRM_GEM_SHMEM_HELPER
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index a57901203aeb..fe3dc8c0db99 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -1162,7 +1162,7 @@ config GREENASIA_FF
>>  
>>  config HID_HYPERV_MOUSE
>>  	tristate "Microsoft Hyper-V mouse driver"
>> -	depends on HYPERV
>> +	depends on HYPERV_VMBUS
>>  	help
>>  	Select this option to enable the Hyper-V mouse driver.
>>  
>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>> index 2e8df09db599..08c4ed005137 100644
>> --- a/drivers/hv/Kconfig
>> +++ b/drivers/hv/Kconfig
>> @@ -44,18 +44,24 @@ config HYPERV_TIMER
>>  
>>  config HYPERV_UTILS
>>  	tristate "Microsoft Hyper-V Utilities driver"
>> -	depends on HYPERV && CONNECTOR && NLS
>> +	depends on HYPERV_VMBUS && 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
>> +	depends on HYPERV_VMBUS
>>  	select PAGE_REPORTING
>>  	help
>>  	  Select this option to enable Hyper-V Balloon driver.
>>  
>> +config HYPERV_VMBUS
>> +	tristate "Microsoft Hyper-V Vmbus driver"
>> +	depends on HYPERV
>> +	help
>> +	  Select this option to enable Hyper-V Vmbus driver.
>> +
>>  config MSHV_ROOT
>>  	tristate "Microsoft Hyper-V root partition support"
>>  	depends on HYPERV && (X86_64 || ARM64)
>> @@ -75,7 +81,7 @@ config MSHV_ROOT
>>  
>>  config MSHV_VTL
>>  	tristate "Microsoft Hyper-V VTL driver"
>> -	depends on X86_64 && HYPERV_VTL_MODE
>> +	depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
>>  	# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
>>  	# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
>>  	# specially with large memory requirements.
>> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
>> index c53a0df746b7..050517756a82 100644
>> --- a/drivers/hv/Makefile
>> +++ b/drivers/hv/Makefile
>> @@ -1,5 +1,5 @@
>>  # SPDX-License-Identifier: GPL-2.0
>> -obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
>> +obj-$(CONFIG_HYPERV_VMBUS)	+= hv_vmbus.o
>>  obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
>>  obj-$(CONFIG_HYPERV_BALLOON)	+= hv_balloon.o
>>  obj-$(CONFIG_MSHV_ROOT)		+= mshv_root.o
>> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
>> index 17edc1597446..c7ef347a4dff 100644
>> --- a/drivers/input/serio/Kconfig
>> +++ b/drivers/input/serio/Kconfig
>> @@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
>>  
>>  config HYPERV_KEYBOARD
>>  	tristate "Microsoft Synthetic Keyboard driver"
>> -	depends on HYPERV
>> -	default HYPERV
>> +	depends on HYPERV_VMBUS
>> +	default HYPERV_VMBUS
>>  	help
>>  	  Select this option to enable the Hyper-V Keyboard driver.
>>  
>> diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
>> index c8cbd85adcf9..982964c1a9fb 100644
>> --- a/drivers/net/hyperv/Kconfig
>> +++ b/drivers/net/hyperv/Kconfig
>> @@ -1,7 +1,7 @@
>>  # SPDX-License-Identifier: GPL-2.0-only
>>  config HYPERV_NET
>>  	tristate "Microsoft Hyper-V virtual network driver"
>> -	depends on HYPERV
>> +	depends on HYPERV_VMBUS
>>  	select UCS2_STRING
>>  	select NLS
>>  	help
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 9a249c65aedc..7065a8e5f9b1 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -221,7 +221,7 @@ config PCI_LABEL
>>  
>>  config PCI_HYPERV
>>  	tristate "Hyper-V PCI Frontend"
>> -	depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
>> +	depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
>>  	select PCI_HYPERV_INTERFACE
>>  	select IRQ_MSI_LIB
>>  	help
>> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>> index 5522310bab8d..19d0884479a2 100644
>> --- a/drivers/scsi/Kconfig
>> +++ b/drivers/scsi/Kconfig
>> @@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
>>  
>>  config HYPERV_STORAGE
>>  	tristate "Microsoft Hyper-V virtual storage driver"
>> -	depends on SCSI && HYPERV
>> +	depends on SCSI && HYPERV_VMBUS
>>  	depends on m || SCSI_FC_ATTRS != m
>>  	default HYPERV
>>  	help
>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>> index b060dcd7c635..6f86a61231e6 100644
>> --- a/drivers/uio/Kconfig
>> +++ b/drivers/uio/Kconfig
>> @@ -140,7 +140,7 @@ config UIO_MF624
>>  
>>  config UIO_HV_GENERIC
>>  	tristate "Generic driver for Hyper-V VMBus"
>> -	depends on HYPERV
>> +	depends on HYPERV_VMBUS
>>  	help
>>  	  Generic driver that you can bind, dynamically, to any
>>  	  Hyper-V VMBus device. It is useful to provide direct access
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index c21484d15f0c..72c63eaeb983 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -1774,7 +1774,7 @@ config FB_BROADSHEET
>>  
>>  config FB_HYPERV
>>  	tristate "Microsoft Hyper-V Synthetic Video support"
>> -	depends on FB && HYPERV
>> +	depends on FB && HYPERV_VMBUS
>>  	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
>>  	select FB_IOMEM_HELPERS_DEFERRED
>>  	help
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index 1d2ad1304ad4..66c58c91b530 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
>>  
>>  void __init hv_mark_resources(void);
>>  
>> +#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
>>  /* Free the message slot and signal end-of-message if required */
>>  static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>>  {
>> @@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>>  	}
>>  }
>>  
>> +extern int vmbus_interrupt;
>> +extern int vmbus_irq;
>> +#endif /* CONFIG_HYPERV_VMBUS */
>> +
>>  int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>>  
>>  void hv_setup_vmbus_handler(void (*handler)(void));
>> @@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
>>  void hv_remove_crash_handler(void);
>>  void hv_setup_mshv_handler(void (*handler)(void));
>>  
>> -extern int vmbus_interrupt;
>> -extern int vmbus_irq;
>> -
>>  #if IS_ENABLED(CONFIG_HYPERV)
>>  /*
>>   * Hypervisor's notion of virtual processor ID is different from
>> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
>> index 56356d2980c8..8e803c4828c4 100644
>> --- a/net/vmw_vsock/Kconfig
>> +++ b/net/vmw_vsock/Kconfig
>> @@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
>>  
>>  config HYPERV_VSOCKETS
>>  	tristate "Hyper-V transport for Virtual Sockets"
>> -	depends on VSOCKETS && HYPERV
>> +	depends on VSOCKETS && HYPERV_VMBUS
>>  	help
>>  	  This module implements a Hyper-V transport for Virtual Sockets.
>>  

RE: [PATCH V0 1/2] hyper-v: Add CONFIG_HYPERV_VMBUS option

[Michael Kelley]

From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
> 

Even though this patch touches multiple subdirectories under "drivers",
I'd suggest the patch "Subject:" prefix should be "Drivers: hv:" (not "hyper-v:")
to be consistent with historical usage.

> Somehow vmbus driver is hinged on CONFIG_HYPERV. It appears this is initial

In text, "vmbus" should be spelled as "VMBus".  This includes patch Subjects,
commit messages, code comments, kernel messages, and kernel documentation.
Originally, the spelling was all over the map, but we've tried to be more consistent
lately in matching Microsoft's public documentation on Hyper-V, which uses
"VMBus". Of course, C language code variable and function names use all lowercase.

> code that did not get addressed when the scope of CONFIG_HYPERV went beyond
> vmbus. This commit creates a fine grained HYPERV_VMBUS option and updates
> drivers that depend on VMBUS.
> 
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
>  drivers/gpu/drm/Kconfig        |  2 +-
>  drivers/hid/Kconfig            |  2 +-
>  drivers/hv/Kconfig             | 12 +++++++++---
>  drivers/hv/Makefile            |  2 +-
>  drivers/input/serio/Kconfig    |  4 ++--
>  drivers/net/hyperv/Kconfig     |  2 +-
>  drivers/pci/Kconfig            |  2 +-
>  drivers/scsi/Kconfig           |  2 +-
>  drivers/uio/Kconfig            |  2 +-
>  drivers/video/fbdev/Kconfig    |  2 +-
>  include/asm-generic/mshyperv.h |  8 +++++---
>  net/vmw_vsock/Kconfig          |  2 +-
>  12 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f7ea8e895c0c..58f34da061c6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
> 
>  config DRM_HYPERV
>  	tristate "DRM Support for Hyper-V synthetic video device"
> -	depends on DRM && PCI && HYPERV
> +	depends on DRM && PCI && HYPERV_VMBUS
>  	select DRM_CLIENT_SELECTION
>  	select DRM_KMS_HELPER
>  	select DRM_GEM_SHMEM_HELPER
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a57901203aeb..fe3dc8c0db99 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1162,7 +1162,7 @@ config GREENASIA_FF
> 
>  config HID_HYPERV_MOUSE
>  	tristate "Microsoft Hyper-V mouse driver"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	help
>  	Select this option to enable the Hyper-V mouse driver.
> 
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 2e8df09db599..08c4ed005137 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -44,18 +44,24 @@ config HYPERV_TIMER
> 
>  config HYPERV_UTILS
>  	tristate "Microsoft Hyper-V Utilities driver"
> -	depends on HYPERV && CONNECTOR && NLS
> +	depends on HYPERV_VMBUS && 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
> +	depends on HYPERV_VMBUS
>  	select PAGE_REPORTING
>  	help
>  	  Select this option to enable Hyper-V Balloon driver.
> 
> +config HYPERV_VMBUS
> +	tristate "Microsoft Hyper-V Vmbus driver"

As described above,
s/Vmbus/VMBus/

> +	depends on HYPERV

Per my comments on the cover letter, could add
"default HYPERV" here to help ease the transition.

> +	help
> +	  Select this option to enable Hyper-V Vmbus driver.

s/Vmbus/VMBus/

> +
>  config MSHV_ROOT
>  	tristate "Microsoft Hyper-V root partition support"
>  	depends on HYPERV && (X86_64 || ARM64)
> @@ -75,7 +81,7 @@ config MSHV_ROOT
> 
>  config MSHV_VTL
>  	tristate "Microsoft Hyper-V VTL driver"
> -	depends on X86_64 && HYPERV_VTL_MODE
> +	depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS

An observation: conceptually I would not expect this driver to
depend on HYPERV_VMBUS because it is not a VMBus driver. But
looking at the code, this is a place where VMBus interrupt handling
bleeds into code that is otherwise just hypervisor functionality. So
evidently the HYPERV_VMBUS dependency is needed for now.
Getting better separation and avoiding the dependency could be
done later.

>  	# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
>  	# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
>  	# specially with large memory requirements.
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index c53a0df746b7..050517756a82 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
> +obj-$(CONFIG_HYPERV_VMBUS)	+= hv_vmbus.o
>  obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
>  obj-$(CONFIG_HYPERV_BALLOON)	+= hv_balloon.o
>  obj-$(CONFIG_MSHV_ROOT)		+= mshv_root.o
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 17edc1597446..c7ef347a4dff 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
> 
>  config HYPERV_KEYBOARD
>  	tristate "Microsoft Synthetic Keyboard driver"
> -	depends on HYPERV
> -	default HYPERV
> +	depends on HYPERV_VMBUS
> +	default HYPERV_VMBUS
>  	help
>  	  Select this option to enable the Hyper-V Keyboard driver.
> 
> diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
> index c8cbd85adcf9..982964c1a9fb 100644
> --- a/drivers/net/hyperv/Kconfig
> +++ b/drivers/net/hyperv/Kconfig
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config HYPERV_NET
>  	tristate "Microsoft Hyper-V virtual network driver"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	select UCS2_STRING
>  	select NLS
>  	help
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9a249c65aedc..7065a8e5f9b1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -221,7 +221,7 @@ config PCI_LABEL
> 
>  config PCI_HYPERV
>  	tristate "Hyper-V PCI Frontend"
> -	depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
> +	depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI
> && SYSFS
>  	select PCI_HYPERV_INTERFACE
>  	select IRQ_MSI_LIB
>  	help
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 5522310bab8d..19d0884479a2 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
> 
>  config HYPERV_STORAGE
>  	tristate "Microsoft Hyper-V virtual storage driver"
> -	depends on SCSI && HYPERV
> +	depends on SCSI && HYPERV_VMBUS
>  	depends on m || SCSI_FC_ATTRS != m
>  	default HYPERV
>  	help
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index b060dcd7c635..6f86a61231e6 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -140,7 +140,7 @@ config UIO_MF624
> 
>  config UIO_HV_GENERIC
>  	tristate "Generic driver for Hyper-V VMBus"
> -	depends on HYPERV
> +	depends on HYPERV_VMBUS
>  	help
>  	  Generic driver that you can bind, dynamically, to any
>  	  Hyper-V VMBus device. It is useful to provide direct access
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c21484d15f0c..72c63eaeb983 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1774,7 +1774,7 @@ config FB_BROADSHEET
> 
>  config FB_HYPERV
>  	tristate "Microsoft Hyper-V Synthetic Video support"
> -	depends on FB && HYPERV
> +	depends on FB && HYPERV_VMBUS
>  	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
>  	select FB_IOMEM_HELPERS_DEFERRED
>  	help
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index 1d2ad1304ad4..66c58c91b530 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
> 
>  void __init hv_mark_resources(void);
> 
> +#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
>  /* Free the message slot and signal end-of-message if required */
>  static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>  {
> @@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
>  	}
>  }
> 
> +extern int vmbus_interrupt;
> +extern int vmbus_irq;
> +#endif /* CONFIG_HYPERV_VMBUS */
> +
>  int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
> 
>  void hv_setup_vmbus_handler(void (*handler)(void));
> @@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
>  void hv_remove_crash_handler(void);
>  void hv_setup_mshv_handler(void (*handler)(void));
> 
> -extern int vmbus_interrupt;
> -extern int vmbus_irq;
> -
>  #if IS_ENABLED(CONFIG_HYPERV)
>  /*
>   * Hypervisor's notion of virtual processor ID is different from
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index 56356d2980c8..8e803c4828c4 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
> 
>  config HYPERV_VSOCKETS
>  	tristate "Hyper-V transport for Virtual Sockets"
> -	depends on VSOCKETS && HYPERV
> +	depends on VSOCKETS && HYPERV_VMBUS
>  	help
>  	  This module implements a Hyper-V transport for Virtual Sockets.
> 
> --
> 2.36.1.vfs.0.0
> 

[PATCH V0 2/2] hyper-v: Make CONFIG_HYPERV bool

[Mukesh Rathor]

CONFIG_HYPERV is an umbrella config option involved in enabling hyperv
support and build of modules like hyperv-balloon, hyperv-vmbus, etc.. As
such it should be bool and the hack in Makefile be removed.

Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
 drivers/Makefile    | 2 +-
 drivers/hv/Kconfig  | 2 +-
 drivers/hv/Makefile | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE)		+= soundwire/
 
 # Virtualization drivers
 obj-$(CONFIG_VIRT_DRIVERS)	+= virt/
-obj-$(subst m,y,$(CONFIG_HYPERV))	+= hv/
+obj-$(CONFIG_HYPERV)		+= hv/
 
 obj-$(CONFIG_PM_DEVFREQ)	+= devfreq/
 obj-$(CONFIG_EXTCON)		+= extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 08c4ed005137..b860bc1026b7 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
 menu "Microsoft Hyper-V guest support"
 
 config HYPERV
-	tristate "Microsoft Hyper-V client drivers"
+	bool "Microsoft Hyper-V client drivers"
 	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
 		|| (ARM64 && !CPU_BIG_ENDIAN)
 	select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 050517756a82..8b04a33e4dd8 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
 mshv_vtl-y := mshv_vtl_main.o
 
 # Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
 obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
 ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
     obj-y += mshv_common.o
-- 
2.36.1.vfs.0.0

RE: [PATCH V0 2/2] hyper-v: Make CONFIG_HYPERV bool

[Michael Kelley]

From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM

Same comment about patch "Subject:" prefix.

> CONFIG_HYPERV is an umbrella config option involved in enabling hyperv

s/hyperv/Hyper-V/

> support and build of modules like hyperv-balloon, hyperv-vmbus, etc..

With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, I think
of CONFIG_HYPERV as the core Hyper-V hypervisor support, such as
hypercalls, clocks/timers, Confidential Computing setup, etc. that
doesn't involve VMBus or VMBus devices.

> As such it should be bool and the hack in Makefile be removed.
> 
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
>  drivers/Makefile    | 2 +-
>  drivers/hv/Kconfig  | 2 +-
>  drivers/hv/Makefile | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index b5749cf67044..7ad5744db0b6 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE)		+= soundwire/
> 
>  # Virtualization drivers
>  obj-$(CONFIG_VIRT_DRIVERS)	+= virt/
> -obj-$(subst m,y,$(CONFIG_HYPERV))	+= hv/
> +obj-$(CONFIG_HYPERV)		+= hv/
> 
>  obj-$(CONFIG_PM_DEVFREQ)	+= devfreq/
>  obj-$(CONFIG_EXTCON)		+= extcon/
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 08c4ed005137..b860bc1026b7 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -3,7 +3,7 @@
>  menu "Microsoft Hyper-V guest support"
> 
>  config HYPERV
> -	tristate "Microsoft Hyper-V client drivers"
> +	bool "Microsoft Hyper-V client drivers"

I would want to change the prompt here to be more specific, such as:

	bool "Microsoft Hyper-V core hypervisor support"

As noted in my comments on the cover letter, this change causes
.config file compatibility problems. I can't immediately think of
a way to deal with the compatibility problem and still change this
from tristate to bool.

>  	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
>  		|| (ARM64 && !CPU_BIG_ENDIAN)
>  	select PARAVIRT
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index 050517756a82..8b04a33e4dd8 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o
> mshv_eventfd.o mshv_irq.o \
>  mshv_vtl-y := mshv_vtl_main.o
> 
>  # Code that must be built-in
> -obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
> +obj-$(CONFIG_HYPERV) += hv_common.o
>  obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
>  ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
>      obj-y += mshv_common.o
> --
> 2.36.1.vfs.0.0
> 

RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Michael Kelley]

From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
> 
> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> built if CONFIG_HYPER is set, either loadable or builtin.
> 
> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
> encompasses builtin code and various other things and not a dedicated config
> option for VMBUS. Vmbus should really have a config option just like
> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
> to build VMBUS driver and make that distinction explicit. With that
> CONFIG_HYPERV could be changed to bool.

Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
is already mostly in separate source files code, though there's some
entanglement in the handling of VMBus interrupts, which could be
improved later.

However, I have a compatibility concern. Consider this scenario:

1) Assume running in a Hyper-V VM with a current Linux kernel version
    built with CONFIG_HYPERV=m.
2) Grab a new version of kernel source code that contains this patch set.
3) Run 'make olddefconfig' to create the .config file for the new kernel.
4) Build the new kernel. This succeeds.
5) Install and run the new kernel in the Hyper-V VM. This fails.

The failure occurs because CONFIG_HYPERV=m is no longer legal,
so the .config file created in Step 3 has CONFIG_HYPERV=n. The
newly built kernel has no Hyper-V support and won't run in a
Hyper-V VM.

As a second issue, if in Step 1 the current kernel was built with
CONFIG_HYPERV=y, then the .config file for the new kernel will have
CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
defaults to 'n', so the new kernel doesn't have any VMBus drivers
and won't run in a typical Hyper-V VM.

The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
a default value, such as whatever CONFIG_HYPERV is set to. But
I'm not sure how to fix the first issue, except by continuing to
allow CONFIG_HYPERV=m. 

See additional minor comments in Patches 1 and 2.

Michael

> 
> For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
> but once merges are mostly done, that and some others should be moved to
> virt/hyperv directory.
> 
> Mukesh Rathor (2):
>   hyper-v: Add CONFIG_HYPERV_VMBUS option
>   hyper-v: Make CONFIG_HYPERV bool
> 
>  drivers/Makefile               |  2 +-
>  drivers/gpu/drm/Kconfig        |  2 +-
>  drivers/hid/Kconfig            |  2 +-
>  drivers/hv/Kconfig             | 14 ++++++++++----
>  drivers/hv/Makefile            |  4 ++--
>  drivers/input/serio/Kconfig    |  4 ++--
>  drivers/net/hyperv/Kconfig     |  2 +-
>  drivers/pci/Kconfig            |  2 +-
>  drivers/scsi/Kconfig           |  2 +-
>  drivers/uio/Kconfig            |  2 +-
>  drivers/video/fbdev/Kconfig    |  2 +-
>  include/asm-generic/mshyperv.h |  8 +++++---
>  net/vmw_vsock/Kconfig          |  2 +-
>  13 files changed, 28 insertions(+), 20 deletions(-)
> 
> --
> 2.36.1.vfs.0.0
> 

Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Mukesh R]

On 9/2/25 07:42, Michael Kelley wrote:
> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>
>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>> built if CONFIG_HYPER is set, either loadable or builtin.
>>
>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>> encompasses builtin code and various other things and not a dedicated config
>> option for VMBUS. Vmbus should really have a config option just like
>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>> to build VMBUS driver and make that distinction explicit. With that
>> CONFIG_HYPERV could be changed to bool.
> 
> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> is already mostly in separate source files code, though there's some
> entanglement in the handling of VMBus interrupts, which could be
> improved later.
> 
> However, I have a compatibility concern. Consider this scenario:
> 
> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>     built with CONFIG_HYPERV=m.
> 2) Grab a new version of kernel source code that contains this patch set.
> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> 4) Build the new kernel. This succeeds.
> 5) Install and run the new kernel in the Hyper-V VM. This fails.
> 
> The failure occurs because CONFIG_HYPERV=m is no longer legal,
> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> newly built kernel has no Hyper-V support and won't run in a
> Hyper-V VM.
> 
> As a second issue, if in Step 1 the current kernel was built with
> CONFIG_HYPERV=y, then the .config file for the new kernel will have
> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> defaults to 'n', so the new kernel doesn't have any VMBus drivers
> and won't run in a typical Hyper-V VM.
> 
> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> a default value, such as whatever CONFIG_HYPERV is set to. But
> I'm not sure how to fix the first issue, except by continuing to
> allow CONFIG_HYPERV=m. 

To certain extent, imo, users are expected to check config files
for changes when moving to new versions/releases, so it would be a 
one time burden. CONFIG_HYPERV=m is just broken imo as one sees that
in .config but magically symbols in drivers/hv are in kerenel.

Thanks,
-Mukesh


> See additional minor comments in Patches 1 and 2.
> 
> Michael
> 
>>
>> For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
>> but once merges are mostly done, that and some others should be moved to
>> virt/hyperv directory.
>>
>> Mukesh Rathor (2):
>>   hyper-v: Add CONFIG_HYPERV_VMBUS option
>>   hyper-v: Make CONFIG_HYPERV bool
>>
>>  drivers/Makefile               |  2 +-
>>  drivers/gpu/drm/Kconfig        |  2 +-
>>  drivers/hid/Kconfig            |  2 +-
>>  drivers/hv/Kconfig             | 14 ++++++++++----
>>  drivers/hv/Makefile            |  4 ++--
>>  drivers/input/serio/Kconfig    |  4 ++--
>>  drivers/net/hyperv/Kconfig     |  2 +-
>>  drivers/pci/Kconfig            |  2 +-
>>  drivers/scsi/Kconfig           |  2 +-
>>  drivers/uio/Kconfig            |  2 +-
>>  drivers/video/fbdev/Kconfig    |  2 +-
>>  include/asm-generic/mshyperv.h |  8 +++++---
>>  net/vmw_vsock/Kconfig          |  2 +-
>>  13 files changed, 28 insertions(+), 20 deletions(-)
>>
>> --
>> 2.36.1.vfs.0.0
>>

RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Michael Kelley]

From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
> 
> On 9/2/25 07:42, Michael Kelley wrote:
> > From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
> >>
> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> >> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> >> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> >> built if CONFIG_HYPER is set, either loadable or builtin.
> >>
> >> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
> >> encompasses builtin code and various other things and not a dedicated config
> >> option for VMBUS. Vmbus should really have a config option just like
> >> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
> >> to build VMBUS driver and make that distinction explicit. With that
> >> CONFIG_HYPERV could be changed to bool.
> >
> > Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> > support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> > is already mostly in separate source files code, though there's some
> > entanglement in the handling of VMBus interrupts, which could be
> > improved later.
> >
> > However, I have a compatibility concern. Consider this scenario:
> >
> > 1) Assume running in a Hyper-V VM with a current Linux kernel version
> >     built with CONFIG_HYPERV=m.
> > 2) Grab a new version of kernel source code that contains this patch set.
> > 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> > 4) Build the new kernel. This succeeds.
> > 5) Install and run the new kernel in the Hyper-V VM. This fails.
> >
> > The failure occurs because CONFIG_HYPERV=m is no longer legal,
> > so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> > newly built kernel has no Hyper-V support and won't run in a
> > Hyper-V VM.
> >
> > As a second issue, if in Step 1 the current kernel was built with
> > CONFIG_HYPERV=y, then the .config file for the new kernel will have
> > CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> > defaults to 'n', so the new kernel doesn't have any VMBus drivers
> > and won't run in a typical Hyper-V VM.
> >
> > The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> > a default value, such as whatever CONFIG_HYPERV is set to. But
> > I'm not sure how to fix the first issue, except by continuing to
> > allow CONFIG_HYPERV=m.
> 
> To certain extent, imo, users are expected to check config files
> for changes when moving to new versions/releases, so it would be a
> one time burden. 

I'm not so sanguine about the impact. For those of us who work with
Hyper-V frequently, yes, it's probably not that big of an issue -- we can
figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
the details of how the Kconfig files are put together. And the issue occurs
with no error messages that something has gone wrong in building
the kernel, except that it won't boot. Just running "make olddefconfig"
has worked in the past, so some users will be befuddled and end up
generating Azure support incidents. I also wonder about breaking
automated test suites for new kernels, as they are likely to be running
"make olddefconfig" or something similar as part of the automation.

> CONFIG_HYPERV=m is just broken imo as one sees that
> in .config but magically symbols in drivers/hv are in kerenel.
> 

I agree that's not ideal. But note that some Hyper-V code and symbols
like ms_hyperv_init_platform() and related functions show up when
CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
is one of the recognized and somewhat hardwired hypervisors (like
VMware, for example).

Finally, there are about a dozen other places in the kernel that use
the same Makefile construct to make some code built-in even though
the CONFIG option is set to "m". That may not be enough occurrences
to make it standard practice, but Hyper-V guests are certainly not the
only case.

In my mind, this is judgment call with no absolute right answer. What
do others think about the tradeoffs?

Michael

Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Mukesh R]

On 9/4/25 09:26, Michael Kelley wrote:
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>
>> On 9/2/25 07:42, Michael Kelley wrote:
>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>
>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>
>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>> encompasses builtin code and various other things and not a dedicated config
>>>> option for VMBUS. Vmbus should really have a config option just like
>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>> to build VMBUS driver and make that distinction explicit. With that
>>>> CONFIG_HYPERV could be changed to bool.
>>>
>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>> is already mostly in separate source files code, though there's some
>>> entanglement in the handling of VMBus interrupts, which could be
>>> improved later.
>>>
>>> However, I have a compatibility concern. Consider this scenario:
>>>
>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>     built with CONFIG_HYPERV=m.
>>> 2) Grab a new version of kernel source code that contains this patch set.
>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>> 4) Build the new kernel. This succeeds.
>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>
>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>> newly built kernel has no Hyper-V support and won't run in a
>>> Hyper-V VM.
>>>
>>> As a second issue, if in Step 1 the current kernel was built with
>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>> and won't run in a typical Hyper-V VM.
>>>
>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>> I'm not sure how to fix the first issue, except by continuing to
>>> allow CONFIG_HYPERV=m.
>>
>> To certain extent, imo, users are expected to check config files
>> for changes when moving to new versions/releases, so it would be a
>> one time burden. 
> 
> I'm not so sanguine about the impact. For those of us who work with
> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
> the details of how the Kconfig files are put together. And the issue occurs
> with no error messages that something has gone wrong in building
> the kernel, except that it won't boot. Just running "make olddefconfig"
> has worked in the past, so some users will be befuddled and end up
> generating Azure support incidents. I also wonder about breaking
> automated test suites for new kernels, as they are likely to be running
> "make olddefconfig" or something similar as part of the automation.
> 
>> CONFIG_HYPERV=m is just broken imo as one sees that
>> in .config but magically symbols in drivers/hv are in kerenel.
>>
> 
> I agree that's not ideal. But note that some Hyper-V code and symbols
> like ms_hyperv_init_platform() and related functions show up when
> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
> is one of the recognized and somewhat hardwired hypervisors (like
> VMware, for example).
> 
> Finally, there are about a dozen other places in the kernel that use
> the same Makefile construct to make some code built-in even though
> the CONFIG option is set to "m". That may not be enough occurrences
> to make it standard practice, but Hyper-V guests are certainly not the
> only case.
> 
> In my mind, this is judgment call with no absolute right answer. What
> do others think about the tradeoffs?

Wei had said in private message that he agrees this is a good idea. Nuno
said earlier above: 

"FWIW I think it's a good idea, interested to hear what others think."

Thanks,
-Mukesh

Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Nuno Das Neves]

On 9/4/2025 11:18 AM, Mukesh R wrote:
> On 9/4/25 09:26, Michael Kelley wrote:
>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>
>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>
>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>
>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>> CONFIG_HYPERV could be changed to bool.
>>>>
>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>> is already mostly in separate source files code, though there's some
>>>> entanglement in the handling of VMBus interrupts, which could be
>>>> improved later.
>>>>
>>>> However, I have a compatibility concern. Consider this scenario:
>>>>
>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>     built with CONFIG_HYPERV=m.
>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>> 4) Build the new kernel. This succeeds.
>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>
>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>> newly built kernel has no Hyper-V support and won't run in a
>>>> Hyper-V VM.

It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
I guess any invalid value turns to =n, which makes sense most of the time.

>>>>
>>>> As a second issue, if in Step 1 the current kernel was built with
>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>> and won't run in a typical Hyper-V VM.
>>>>
>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>> I'm not sure how to fix the first issue, except by continuing to
>>>> allow CONFIG_HYPERV=m.

I'm wondering, is there a path for this change, then? Are there some
intermediate step/s we could take to minimize the problem?

>>>
>>> To certain extent, imo, users are expected to check config files
>>> for changes when moving to new versions/releases, so it would be a
>>> one time burden. 
>>
>> I'm not so sanguine about the impact. For those of us who work with
>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>> the details of how the Kconfig files are put together. And the issue occurs
>> with no error messages that something has gone wrong in building
>> the kernel, except that it won't boot. Just running "make olddefconfig"
>> has worked in the past, so some users will be befuddled and end up
>> generating Azure support incidents. I also wonder about breaking
>> automated test suites for new kernels, as they are likely to be running
>> "make olddefconfig" or something similar as part of the automation.
>>
>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>
>>
>> I agree that's not ideal. But note that some Hyper-V code and symbols
>> like ms_hyperv_init_platform() and related functions show up when
>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>> is one of the recognized and somewhat hardwired hypervisors (like
>> VMware, for example).
>>
>> Finally, there are about a dozen other places in the kernel that use
>> the same Makefile construct to make some code built-in even though
>> the CONFIG option is set to "m". That may not be enough occurrences
>> to make it standard practice, but Hyper-V guests are certainly not the
>> only case.
>>
>> In my mind, this is judgment call with no absolute right answer. What
>> do others think about the tradeoffs?
> 
> Wei had said in private message that he agrees this is a good idea. Nuno
> said earlier above: 
> 
> "FWIW I think it's a good idea, interested to hear what others think."
> 
That was before Michael pointed out the potential issues which I was
unaware of. Let's see if there's a path that is smoother for all the
downstream users who may be compiling with CONFIG_HYPERV=m.

Nuno

> Thanks,> -Mukesh
> 
> 

Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Mukesh R]

On 9/5/25 13:08, Nuno Das Neves wrote:
> On 9/4/2025 11:18 AM, Mukesh R wrote:
>> On 9/4/25 09:26, Michael Kelley wrote:
>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>
>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>
>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>
>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>
>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>> is already mostly in separate source files code, though there's some
>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>> improved later.
>>>>>
>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>
>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>>     built with CONFIG_HYPERV=m.
>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>> 4) Build the new kernel. This succeeds.
>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>
>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>> Hyper-V VM.
> 
> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
> I guess any invalid value turns to =n, which makes sense most of the time.
> 
>>>>>
>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>> and won't run in a typical Hyper-V VM.
>>>>>
>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>> allow CONFIG_HYPERV=m.
> 
> I'm wondering, is there a path for this change, then? Are there some
> intermediate step/s we could take to minimize the problem?
> 
>>>>
>>>> To certain extent, imo, users are expected to check config files
>>>> for changes when moving to new versions/releases, so it would be a
>>>> one time burden. 
>>>
>>> I'm not so sanguine about the impact. For those of us who work with
>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>> the details of how the Kconfig files are put together. And the issue occurs
>>> with no error messages that something has gone wrong in building
>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>> has worked in the past, so some users will be befuddled and end up
>>> generating Azure support incidents. I also wonder about breaking
>>> automated test suites for new kernels, as they are likely to be running
>>> "make olddefconfig" or something similar as part of the automation.
>>>
>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>
>>>
>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>> like ms_hyperv_init_platform() and related functions show up when
>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>> is one of the recognized and somewhat hardwired hypervisors (like
>>> VMware, for example).
>>>
>>> Finally, there are about a dozen other places in the kernel that use
>>> the same Makefile construct to make some code built-in even though
>>> the CONFIG option is set to "m". That may not be enough occurrences
>>> to make it standard practice, but Hyper-V guests are certainly not the
>>> only case.
>>>
>>> In my mind, this is judgment call with no absolute right answer. What
>>> do others think about the tradeoffs?
>>
>> Wei had said in private message that he agrees this is a good idea. Nuno
>> said earlier above: 
>>
>> "FWIW I think it's a good idea, interested to hear what others think."
>>
> That was before Michael pointed out the potential issues which I was
> unaware of. Let's see if there's a path that is smoother for all the
> downstream users who may be compiling with CONFIG_HYPERV=m.

Ok, we've already thought of it for sometime and not able to come up
with any. IMO, it's a minor hickup, not major. This is stalling
upcoming iommu and other patches which will use CONFIG_HYPERV and 
add more dependencies, and it would be much harder to straighten 
out then. So I hope you guys can come up with some solution sooner than
later, I can't think of any.

Thanks,
-Mukesh

Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly

[Mukesh R]

On 9/5/25 14:41, Mukesh R wrote:
> On 9/5/25 13:08, Nuno Das Neves wrote:
>> On 9/4/2025 11:18 AM, Mukesh R wrote:
>>> On 9/4/25 09:26, Michael Kelley wrote:
>>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>>
>>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>>
>>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>>
>>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>>
>>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>>> is already mostly in separate source files code, though there's some
>>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>>> improved later.
>>>>>>
>>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>>
>>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>>>     built with CONFIG_HYPERV=m.
>>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>>> 4) Build the new kernel. This succeeds.
>>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>>
>>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>>> Hyper-V VM.
>>
>> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
>> I guess any invalid value turns to =n, which makes sense most of the time.
>>
>>>>>>
>>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>>> and won't run in a typical Hyper-V VM.
>>>>>>
>>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>>> allow CONFIG_HYPERV=m.
>>
>> I'm wondering, is there a path for this change, then? Are there some
>> intermediate step/s we could take to minimize the problem?
>>
>>>>>
>>>>> To certain extent, imo, users are expected to check config files
>>>>> for changes when moving to new versions/releases, so it would be a
>>>>> one time burden. 
>>>>
>>>> I'm not so sanguine about the impact. For those of us who work with
>>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>>> the details of how the Kconfig files are put together. And the issue occurs
>>>> with no error messages that something has gone wrong in building
>>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>>> has worked in the past, so some users will be befuddled and end up
>>>> generating Azure support incidents. I also wonder about breaking
>>>> automated test suites for new kernels, as they are likely to be running
>>>> "make olddefconfig" or something similar as part of the automation.
>>>>
>>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>>
>>>>
>>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>>> like ms_hyperv_init_platform() and related functions show up when
>>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>>> is one of the recognized and somewhat hardwired hypervisors (like
>>>> VMware, for example).
>>>>
>>>> Finally, there are about a dozen other places in the kernel that use
>>>> the same Makefile construct to make some code built-in even though
>>>> the CONFIG option is set to "m". That may not be enough occurrences
>>>> to make it standard practice, but Hyper-V guests are certainly not the
>>>> only case.
>>>>
>>>> In my mind, this is judgment call with no absolute right answer. What
>>>> do others think about the tradeoffs?
>>>
>>> Wei had said in private message that he agrees this is a good idea. Nuno
>>> said earlier above: 
>>>
>>> "FWIW I think it's a good idea, interested to hear what others think."
>>>
>> That was before Michael pointed out the potential issues which I was
>> unaware of. Let's see if there's a path that is smoother for all the
>> downstream users who may be compiling with CONFIG_HYPERV=m.
> 
> Ok, we've already thought of it for sometime and not able to come up
> with any. IMO, it's a minor hickup, not major. This is stalling
> upcoming iommu and other patches which will use CONFIG_HYPERV and 
> add more dependencies, and it would be much harder to straighten 
> out then. So I hope you guys can come up with some solution sooner than
> later, I can't think of any.

Played around a bit, setting it to "default HYPERV" like Michael suggested
gives it a default value of y. I thought it fail if one is bool and other
is tristate. So that should help with transition.

Thanks,
-Mukesh