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
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"configDRM_HYPERVtristate"DRM Support for Hyper-V synthetic video device"-depends onDRM&&PCI&&HYPERV+depends onDRM&&PCI&&HYPERV_VMBUSselectDRM_CLIENT_SELECTIONselectDRM_KMS_HELPERselectDRM_GEM_SHMEM_HELPER
@@ -75,7 +81,7 @@ config MSHV_ROOTconfigMSHV_VTLtristate"Microsoft Hyper-V VTL driver"-depends onX86_64&&HYPERV_VTL_MODE+depends onX86_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.
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)void__inithv_mark_resources(void);+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)/* Free the message slot and signal end-of-message if required */staticinlinevoidvmbus_signal_eom(structhv_message*msg,u32old_msg_type){
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 <redacted>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
From: Nuno Das Neves <hidden> Date: 2025-08-29 00:29:18
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
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"configDRM_HYPERVtristate"DRM Support for Hyper-V synthetic video device"-depends onDRM&&PCI&&HYPERV+depends onDRM&&PCI&&HYPERV_VMBUSselectDRM_CLIENT_SELECTIONselectDRM_KMS_HELPERselectDRM_GEM_SHMEM_HELPER
@@ -75,7 +81,7 @@ config MSHV_ROOTconfigMSHV_VTLtristate"Microsoft Hyper-V VTL driver"-depends onX86_64&&HYPERV_VTL_MODE+depends onX86_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.
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)void__inithv_mark_resources(void);+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)/* Free the message slot and signal end-of-message if required */staticinlinevoidvmbus_signal_eom(structhv_message*msg,u32old_msg_type){
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
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"configDRM_HYPERVtristate"DRM Support for Hyper-V synthetic video device"-depends onDRM&&PCI&&HYPERV+depends onDRM&&PCI&&HYPERV_VMBUSselectDRM_CLIENT_SELECTIONselectDRM_KMS_HELPERselectDRM_GEM_SHMEM_HELPER
@@ -75,7 +81,7 @@ config MSHV_ROOTconfigMSHV_VTLtristate"Microsoft Hyper-V VTL driver"-depends onX86_64&&HYPERV_VTL_MODE+depends onX86_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.
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)void__inithv_mark_resources(void);+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)/* Free the message slot and signal end-of-message if required */staticinlinevoidvmbus_signal_eom(structhv_message*msg,u32old_msg_type){
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
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.
quoted hunk
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 <redacted>
---
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(-)
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"configDRM_HYPERVtristate"DRM Support for Hyper-V synthetic video device"-depends onDRM&&PCI&&HYPERV+depends onDRM&&PCI&&HYPERV_VMBUSselectDRM_CLIENT_SELECTIONselectDRM_KMS_HELPERselectDRM_GEM_SHMEM_HELPER
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.
quoted hunk
# 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.
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)void__inithv_mark_resources(void);+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)/* Free the message slot and signal end-of-message if required */staticinlinevoidvmbus_signal_eom(structhv_message*msg,u32old_msg_type){
From: Michael Kelley <hidden> Date: 2025-09-02 14:42:50
From: Mukesh Rathor <redacted> 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.
quoted hunk
As such it should be bool and the hack in Makefile be removed.
Signed-off-by: Mukesh Rathor <redacted>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
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.
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
quoted
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
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
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.
quoted
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
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.
quoted
quoted
quoted
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?
quoted
quoted
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.
quoted
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
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.
quoted
quoted
quoted
quoted
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?
quoted
quoted
quoted
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.
quoted
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
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.
quoted
quoted
quoted
quoted
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?
quoted
quoted
quoted
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.
quoted
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