[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SN6PR02MB4157917D84D00DBDAF54BD69D406A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 2 Sep 2025 14:42:23 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Mukesh Rathor <mrathor@...ux.microsoft.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>
CC: "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
"simona@...ll.ch" <simona@...ll.ch>, "jikos@...nel.org" <jikos@...nel.org>,
"bentiss@...nel.org" <bentiss@...nel.org>, "kys@...rosoft.com"
<kys@...rosoft.com>, "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>, "decui@...rosoft.com"
<decui@...rosoft.com>, "dmitry.torokhov@...il.com"
<dmitry.torokhov@...il.com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>, "bhelgaas@...gle.com"
<bhelgaas@...gle.com>, "James.Bottomley@...senPartnership.com"
<James.Bottomley@...senPartnership.com>, "martin.petersen@...cle.com"
<martin.petersen@...cle.com>, "gregkh@...uxfoundation.org"
<gregkh@...uxfoundation.org>, "deller@....de" <deller@....de>,
"arnd@...db.de" <arnd@...db.de>, "sgarzare@...hat.com" <sgarzare@...hat.com>,
"horms@...nel.org" <horms@...nel.org>
Subject: RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor <mrathor@...ux.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.
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
>
Powered by blists - more mailing lists