On 9/2/25 07:42, Michael Kelley wrote: > From: Mukesh Rathor <mrat...@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 >>
