[PATCH 06/11] Drivers: hv: Make sint vector architecture neutral in MSHV_VTL

[Michael Kelley]

From: Naman Jain <namjain at linux.microsoft.com> Sent: Monday, April 13, 2026 4:48 AM
> 
> On 4/1/2026 10:27 PM, Michael Kelley wrote:
> > From: Naman Jain <namjain at linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
> >>
> >> Generalize Synthetic interrupt source vector (sint) to use
> >> vmbus_interrupt variable instead, which automatically takes care of
> >> architectures where HYPERVISOR_CALLBACK_VECTOR is not present (arm64).
> >
> > Sashiko AI raised an interesting question about the startup timing --
> > whether the vmbus_platform_driver_probe() is guaranteed to have
> > set vmbus_interrupt before the VTL functions below run and use it.
> > What causes the mshv_vtl.ko module to be loaded, and hence run
> > mshv_vtl_init()?
> 
> There is no race condition here. The init ordering guarantees that
> vmbus_interrupt is always set before mshv_vtl_synic_enable_regs()
> reads it.
> 
> The call chain for setting vmbus_interrupt:
> 
>    subsys_initcall(hv_acpi_init)                          [level 4]
>      -> platform_driver_register(&vmbus_platform_driver) and so on.
> 
> 
> The call chain for reading vmbus_interrupt:
> 
>    module_init(mshv_vtl_init)                             [level 6]
>      -> hv_vtl_setup_synic()
>        -> cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ..., mshv_vtl_alloc_context, ...)
>          -> mshv_vtl_alloc_context()
>            -> mshv_vtl_synic_enable_regs()
>              -> sint.vector = vmbus_interrupt
> 
> do_initcalls() processes sections in order 0 through 7, so
> hv_acpi_init() (level 4) is guaranteed to complete before
> mshv_vtl_init() (level 6) runs.
> 

I think the situation is more complex than what you describe, depending
on whether the VMBus driver and/or MSHV_VTL are built as modules vs.
being built-in to the kernel image. In include/linux/module.h, see the
comment for module_init() and how subsys_initcall() is mapped
to module_init() when built as a module.

If both are built-in, then what you describe is correct. But if either or
both are modules, then the respective init functions (hv_acpi_init
and mshv_vtl_init) get called at the time the module is loaded, and
not by do_initcalls(). I think hv_vmbus.ko gets loaded when an attempt
is first made to access a disk, but I would need to look more closely to
be sure. I don't have any understanding of what causes mshv_vtl.ko
to be loaded. And what is the ordering if MSHV_VTL is built-in while
VMBus is built as a module, or vice versa?

Michael