From: Jork Loeser <[email protected]> Sent: Wednesday, May 20, 2026 10:16 AM > > On Wed, 20 May 2026, Arnd Bergmann wrote: > > > From: Arnd Bergmann <[email protected]> > > > > When the vmbus driver is not part of the kernel, the mvhv_root > > driver now fails to link: > > > > ERROR: modpost: "hv_vmbus_exists" [drivers/hv/mshv_root.ko] undefined! > > > > Avoid this by adding an explicit Kconfig dependency. Note that > > stubbing out the hv_vmbus_exists() based on configuration would > > also work for some cases, but not with MSHV_ROOT=y and HYPERV_VMBUS=m. > > > > Fixes: f1a9e67c1138 ("mshv: limit SynIC management to MSHV-owned resources") > > Signed-off-by: Arnd Bergmann <[email protected]> > > --- > > drivers/hv/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig > > index 52af086fdeb2..21193b571a80 100644 > > --- a/drivers/hv/Kconfig > > +++ b/drivers/hv/Kconfig > > @@ -75,6 +75,7 @@ config MSHV_ROOT > > # e.g. When withdrawing memory, the hypervisor gives back 4k pages in > > # no particular order, making it impossible to reassemble larger pages > > depends on PAGE_SIZE_4KB > > + depends on HYPERV_VMBUS > > select EVENTFD > > select VIRT_XFER_TO_GUEST_WORK > > select HMM_MIRROR > > -- > > 2.39.5 > > > > Yes, this is the right short-term fix. We will need to solve the root case > (no VMBUS required) with a separate SYNIC driver abstraction. > > Reviewed-by: Jork Loeser <[email protected]> >
I have what I think is a better way to fix this. It preserves the ability to build MSHV without VMBus, while also guaranteeing that VMBus loads first when present. And it is relatively simple -- hv_vmbus_exists() does not need to be moved out of the VMBus module. Later today I'll post a separate patch for consideration. The separate SynIC driver abstraction can still come later and improve things further. Michael
