From: Mukesh R <redacted> Sent: Wednesday, September 3, 2025 7:17 PM

On 9/2/25 07:42, Michael Kelley wrote:

quoted

From: Mukesh Rathor <redacted> Sent: Wednesday, August 27, 2025 6:00 PM

quoted

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