From: Naman Jain <[email protected]> Sent: Monday, April 13, 2026 4:48 AM > > On 4/1/2026 10:27 PM, Michael Kelley wrote: > > From: Naman Jain <[email protected]> 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
