With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.
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 fe29f8dca2b5..7e56c51c5080 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 core hypervisor support"
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.0On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote: > With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV > to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V > hypervisor support, such as hypercalls, clocks/timers, Confidential > Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus > devices. But why are you making it so that this can not be a module anymore? You are now forcing ALL Linux distro users to always have this code in their system, despite not ever using the feature. That feels like a waste to me. What is preventing this from staying as a module? Why must you always have this code loaded at all times for everyone? thanks, greg k-h
On 9/6/25 04:36, Greg KH wrote: > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote: >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V >> hypervisor support, such as hypercalls, clocks/timers, Confidential >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus >> devices. > > But why are you making it so that this can not be a module anymore? You > are now forcing ALL Linux distro users to always have this code in their > system, despite not ever using the feature. That feels like a waste to > me. > > What is preventing this from staying as a module? Why must you always > have this code loaded at all times for everyone? This is currently not a module. I assume it was at the beginning. In drivers/Makefile today: obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/ More context: CONFIG_HYPERV doesn't really reflect one module. It is both for kernel built in code and building of stuff in drivers/hv. drivers/hv then builds 4 modules: obj-$(CONFIG_HYPERV) += hv_vmbus.o obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o obj-$(CONFIG_MSHV_ROOT) += mshv_root.o Notice vmbus is using CONFIG_HYPERV because there is no CONFIG_HYPERV_VMBUS. We are trying to fix that here. Thanks, -Mukesh > thanks, > > greg k-h
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote: > On 9/6/25 04:36, Greg KH wrote: > > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote: > >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV > >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V > >> hypervisor support, such as hypercalls, clocks/timers, Confidential > >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus > >> devices. > > > > But why are you making it so that this can not be a module anymore? You > > are now forcing ALL Linux distro users to always have this code in their > > system, despite not ever using the feature. That feels like a waste to > > me. > > > > What is preventing this from staying as a module? Why must you always > > have this code loaded at all times for everyone? > > This is currently not a module. I assume it was at the beginning. In > drivers/Makefile today: > > obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/ > > > More context: CONFIG_HYPERV doesn't really reflect one module. It is > both for kernel built in code and building of stuff in drivers/hv. > > drivers/hv then builds 4 modules: > > obj-$(CONFIG_HYPERV) += hv_vmbus.o > obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o > obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o > obj-$(CONFIG_MSHV_ROOT) += mshv_root.o > > Notice vmbus is using CONFIG_HYPERV because there is no > CONFIG_HYPERV_VMBUS. We are trying to fix that here. This series does not apply to my tree: checking file drivers/gpu/drm/Kconfig checking file drivers/hid/Kconfig checking file drivers/hv/Kconfig Hunk #2 FAILED at 82. 1 out of 2 hunks FAILED checking file drivers/hv/Makefile checking file drivers/input/serio/Kconfig checking file drivers/net/hyperv/Kconfig checking file drivers/pci/Kconfig checking file drivers/scsi/Kconfig checking file drivers/uio/Kconfig checking file drivers/video/fbdev/Kconfig checking file include/asm-generic/mshyperv.h Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines). Hunk #2 succeeded at 198 (offset -3 lines). Hunk #3 succeeded at 215 (offset -3 lines). checking file net/vmw_vsock/Kconfig What was it made against? thanks, greg k-h
On 9/12/25 04:43, Greg KH wrote: > On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote: >> On 9/6/25 04:36, Greg KH wrote: >>> On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote: >>>> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV >>>> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V >>>> hypervisor support, such as hypercalls, clocks/timers, Confidential >>>> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus >>>> devices. >>> >>> But why are you making it so that this can not be a module anymore? You >>> are now forcing ALL Linux distro users to always have this code in their >>> system, despite not ever using the feature. That feels like a waste to >>> me. >>> >>> What is preventing this from staying as a module? Why must you always >>> have this code loaded at all times for everyone? >> >> This is currently not a module. I assume it was at the beginning. In >> drivers/Makefile today: >> >> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/ >> >> >> More context: CONFIG_HYPERV doesn't really reflect one module. It is >> both for kernel built in code and building of stuff in drivers/hv. >> >> drivers/hv then builds 4 modules: >> >> obj-$(CONFIG_HYPERV) += hv_vmbus.o >> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o >> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o >> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o >> >> Notice vmbus is using CONFIG_HYPERV because there is no >> CONFIG_HYPERV_VMBUS. We are trying to fix that here. > > This series does not apply to my tree: > > checking file drivers/gpu/drm/Kconfig > checking file drivers/hid/Kconfig > checking file drivers/hv/Kconfig > Hunk #2 FAILED at 82. > 1 out of 2 hunks FAILED > checking file drivers/hv/Makefile > checking file drivers/input/serio/Kconfig > checking file drivers/net/hyperv/Kconfig > checking file drivers/pci/Kconfig > checking file drivers/scsi/Kconfig > checking file drivers/uio/Kconfig > checking file drivers/video/fbdev/Kconfig > checking file include/asm-generic/mshyperv.h > Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines). > Hunk #2 succeeded at 198 (offset -3 lines). > Hunk #3 succeeded at 215 (offset -3 lines). > checking file net/vmw_vsock/Kconfig > > What was it made against? > Sorry to hear that. It was built against hyper-next, but perhaps I accidentally used our internal mirror. Let me rebase and send V2 right away. Thanks, -Mukesh
On Fri, Sep 12, 2025 at 11:10:00AM -0700, Mukesh R wrote: [...] > > What was it made against? > > > > Sorry to hear that. It was built against hyper-next, but perhaps I > accidentally used our internal mirror. Let me rebase and send V2 > right away. Sorry for the late reply -- I was away for two weeks. I can pick this series up. Greg, feel free to ignore this series. Wei > > Thanks, > -Mukesh > > >
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote: > On 9/6/25 04:36, Greg KH wrote: > > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote: > >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV > >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V > >> hypervisor support, such as hypercalls, clocks/timers, Confidential > >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus > >> devices. > > > > But why are you making it so that this can not be a module anymore? You > > are now forcing ALL Linux distro users to always have this code in their > > system, despite not ever using the feature. That feels like a waste to > > me. > > > > What is preventing this from staying as a module? Why must you always > > have this code loaded at all times for everyone? > > This is currently not a module. I assume it was at the beginning. In > drivers/Makefile today: > > obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/ > > > More context: CONFIG_HYPERV doesn't really reflect one module. It is > both for kernel built in code and building of stuff in drivers/hv. > > drivers/hv then builds 4 modules: > > obj-$(CONFIG_HYPERV) += hv_vmbus.o > obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o > obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o > obj-$(CONFIG_MSHV_ROOT) += mshv_root.o > > Notice vmbus is using CONFIG_HYPERV because there is no > CONFIG_HYPERV_VMBUS. We are trying to fix that here. Ah, I missed that this was getting changed in the Makefile in patch 1, that is what I was worried about. Nevermind, this should be fine, sorry for the noise. I'll go queue it up later today. greg k-h
© 2016 - 2026 Red Hat, Inc.