From: Mukesh R <mrat...@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM > > 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.
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
