From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B56ECF34C65 for ; Mon, 13 Apr 2026 16:52:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BZg4EuUfpHNS+JSwjQ1D2m4I/BJ7BVsxLCpbabF/7+U=; b=mBjcaVRBF/LsRmOkHqTjPOkQz/ 2eDKvxKTxlDYrMxcMiVsI+xL55nGu/cqLGlv9GAbQSYqEwKC2O25NCN0Dk9tIV0W/PlGIDlaZKoba dK4TFTrhugkzXBLxLU5gDgjuvbtU/wen9SeKN/qGqYKLpmNl0Ghq67H9L1J7ypw5Nc/Urp8cuKlrF UZqZW9MwbFEOgopCfNr8PtbnLRlKERWWF2vtnmU66N4+JKIUZg8XaMj69zYeZ8MGKmeBfO4FRk3GO 4hiJx3V9Bhu/5IOwL8SHaopHnT24itEE92N5boTZZit095tIbgsOwkK6FD9Gcg5tPxnucvOWOT47w Ue2L9+ZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wCKW0-0000000G578-1ECB; Mon, 13 Apr 2026 16:52:00 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wCKVx-0000000G56k-3BTB; Mon, 13 Apr 2026 16:51:58 +0000 Received: from [192.168.0.106] (unknown [49.205.253.198]) by linux.microsoft.com (Postfix) with ESMTPSA id 4DCF620B6F01; Mon, 13 Apr 2026 09:51:50 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4DCF620B6F01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1776099116; bh=BZg4EuUfpHNS+JSwjQ1D2m4I/BJ7BVsxLCpbabF/7+U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=F8eRxB/+wsF8U83KHRZ7cGnuJTXK5ScgYWX22s7lQ01sfWax4WFRBAp9xYWL/CNID q09Rk6ZIJASUKh7q2NOci1dN+XraY4q45tViJ0uFadXnEvrwoBJgWYZpiE3cTp6T9j esOfCpHOGKPfaTr4Wp5rVM7XMgeDVZeMzjIHtFi4= Message-ID: <3264b2e6-f6fb-41b1-97da-22b5249c1839@linux.microsoft.com> Date: Mon, 13 Apr 2026 22:21:47 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/11] Drivers: hv: Make sint vector architecture neutral in MSHV_VTL To: Michael Kelley , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "H . Peter Anvin" , Arnd Bergmann , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti Cc: Marc Zyngier , Timothy Hayes , Lorenzo Pieralisi , mrigendrachaubey , "ssengar@linux.microsoft.com" , "linux-hyperv@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-riscv@lists.infradead.org" References: <20260316121241.910764-1-namjain@linux.microsoft.com> <20260316121241.910764-7-namjain@linux.microsoft.com> Content-Language: en-US From: Naman Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260413_095157_838306_C26D52E1 X-CRM114-Status: GOOD ( 21.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/13/2026 9:19 PM, Michael Kelley wrote: > From: Naman Jain Sent: Monday, April 13, 2026 4:48 AM >> >> On 4/1/2026 10:27 PM, Michael Kelley wrote: >>> From: Naman Jain 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 > Based on this, I still feel that this race is not possible. hv_vmbus mshv_vtl y y -> different initcall levels, no issues y m -> use without initialization is not possible m y -> config dependencies take care of this, and mshv_vtl is forced to compile as a module in this case. m m -> config and symbol dependencies should take care of it. mshv_vtl has symbol and config dependencies on hv_vmbus, and it won't allow loading mshv_vtl if hv_vmbus module is not loaded. Relevant code here: kernel/module/main.c Regards, Naman