From: Easwar Hariharan <[email protected]> Sent: Tuesday, August 4, 2026 3:49 PM > > On 8/4/2026 15:47, Easwar Hariharan wrote: > > On 8/4/2026 15:17, Michael Kelley wrote: > >> From: Easwar Hariharan <[email protected]> Sent: > >> Tuesday, August 4, 2026 12:40 PM > >>> > >>> On 8/4/2026 12:05, Michael Kelley wrote: > >>>> The VMBus module should not be loaded when Linux is running directly > >>>> in the root partition and root is not nested in another VM. Current > >>>> code checks this condition and skips VMBus module initialization, which > >>>> works. But it returns 0 as the result, so Linux thinks the module has > >>>> successfully loaded. Later, if the module were to be unloaded, the > >>>> VMBus module unload code tries to clean up things that were never > >>>> initialized, resulting in memory faults and a panic. > >>>> > >>>> Fix this by having VMBus module initialization return -ENODEV for this > >>>> case. The module is then not loaded, and the unload path can never run. > >>>> > >>>> Reported-by: Sashiko <[email protected]> > >>>> Closes: https://lore.kernel.org/linux- > >>> hyperv/[email protected]/ > >>>> Fixes: 7e279d78664aa ("Drivers: hv: vmbus: skip VMBus initialization if > >>>> Linux is root") > >>>> Signed-off-by: Michael Kelley <[email protected]> > >>>> --- > >>>> drivers/hv/vmbus_drv.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > >>>> index e19ec73b0187..849d7e1a7320 100644 > >>>> --- a/drivers/hv/vmbus_drv.c > >>>> +++ b/drivers/hv/vmbus_drv.c > >>>> @@ -2976,7 +2976,7 @@ static int __init hv_acpi_init(void) > >>>> return -ENODEV; > >>>> > >>>> if (hv_root_partition() && !hv_nested) > >>>> - return 0; > >>>> + return -ENODEV; > >>>> > >>>> /* > >>>> * Get ACPI resources first. > >>> > >>> This seems straightforward: > >> > >> Alas, it's not so straightforward, as Sashiko pointed out. I knew that > >> the mshv module has a dependency on the vmbus module, but had > >> forgotten. There's a reason for the dependency as described in the > >> commit message for 840b740a35bf. > >> > >> There's another easy way to fix the VMBus module unload problem. > >> I'll send a v2. :-) > >> > >> Michael > >> > > I may be missing something, but mshv_root is used in 3 cases: > > > > 1) Baremetal root partition, which requires no VMBus > > > > 2) L1VH aka Direct Virtualization, which is conditioned on > > hv_l1vh_partition(), which is > not the check here in the vmbus driver > > > > 3) For the OpenHCL paravisor, where I honestly don't know what the > > dependency > chain looks like, but based on a quick glance > > at https://github.com/microsoft/OHCL-Linux-Kernel/ and a cursory grep, > > doesn't > seem to rely on hv_root_partition() but does rely > > on VMbus. > > > > I feel like Sashiko's review falls into item 1, but then again, there may > > just be a > mismatch > > between reality and my mental model, or my mental model may becorrect, but > > the > code doesn't match it. > > > > Thanks, > > Easwar (he/him) > > > Well, number 4 is as a parent on a nested hypervisor, but !hv_nested takes > care of that. >
For your #1, indeed the root partition does not require actual VMBus functionality. But it *does* require that the VMBus module be loaded if CONFIG_HYPERV_VMBUS=y. In that case, the only function the root requires for #1 is the function hv_vmbus_exists(), and it requires that to distinguish between your #1 and your #4 when it sets up the SynIC. If you want to build an image that only works for #1, then build with CONFIG_HYPERV_VMBUS=n and there's no issue. But if you want an image that works for #1 or #4, build with CONFIG_HYPERV_VMBUS=y or =m, and the VMBus module must loaded so that hv_vmbus_exists() gives the right answer (false for #1, true for #4). Furthermore, the mshv_root dependency on the VMBus module ensures that the VMBus module is always loaded before the mshv_root module so that hv_vmbus_exists() will give an up-to-date answer when mshv_root asks. The way the SynIC is managed should be refactored to better handle #4, as Jork Loeser has proposed. Hopefully such a refactoring would make the mshv_root->vmbus dependency go away. But until such a refactoring is done, the dependency is what we have. I agree that your #2 and #3 are not relevant here. Michael
