From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 10B3B1FBA5; Mon, 16 Jun 2025 16:08:01 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id CEA681FB81; Mon, 16 Jun 2025 16:07:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by atuin.qyliss.net (Postfix) with ESMTPS id 1AA7B1FB80 for ; Mon, 16 Jun 2025 16:07:57 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-442e9c00bf4so39892515e9.3 for ; Mon, 16 Jun 2025 09:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1750090071; x=1750694871; darn=spectrum-os.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=66enaQYzVszRsP2d3FubStZt1y7rSXnP5cI/cUMaHAc=; b=ziemY0gKjLbKzV0Cc+ozW2u7Ym3R4iAiVNNh+SfAud0rqXO6h3evd6CbNdVLRyr7Lu HceaO1SHDa6tT2F7g+OPKsaCnxzvPp3wNZR658eIDpDIo/JilYwqacTHTjoRhdoMu8FG 9uLa1jwDgJvgn7dOpSvlifIQ663THympsmysRyd+KRBleeIKArAR0kKWp2QIAGa01nAs /15kOQvGEDST+xIwISZBPc8DSYVlXkpsk4q3wzoxXoNwwV1NiBzQ2nxNVZfq3wbcrAq+ 7cff90KJ8B45f3nDQnxpZHeQIi4nyxv4er6OHCxWE2KwslW++KyJQ6Nj9arQ/jy2rF2n 4FdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750090071; x=1750694871; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=66enaQYzVszRsP2d3FubStZt1y7rSXnP5cI/cUMaHAc=; b=Sl25Qa05FIOrN7tLog3WONyzQQhnatXNPAeMwz7x20jtvcIhu047CETcOXf0p4lTPp NFby/6mVMv0qqXFke1sIFpEgVZMVlklhJVh+YZE0vOrItQX92R7P0XuAgcz1BJxg956x 12Ppzm5GjYDLfJfw5NQ7H0KHLbJlMKBDsjlqIeUtRM3t3JWO1ni+2irhUq3DdlEw1CjC B76qh3kipoTunOzveLrZOaIgIlh8XSBTn+GOookbZecXoTI30YUx04AastBFH70YTl8E gMEywsa9z6YzxBpR82a1W1nZ4a/Qooy7JfaWeVicyafjYUFfpvf7vTe3aSTHxP6p78qS h7Fw== X-Forwarded-Encrypted: i=1; AJvYcCXt5mzp7XwClrq+Id1UqM0sc181q5voFg6h5e/l/HZe/1N38KlwL9N+aMYmMlSH2GO1K061/A==@spectrum-os.org X-Gm-Message-State: AOJu0YykN39XxhLQJrunBs1gUd2+3gsK5oyZcNpp3WN52EhKGiUOVPrt tfSekWPr9EdkMjjI5UGhx9pXgcsKZ8TSTDPwZAFMvza7MYsyJQSSasqwJtwLhJbtC4g= X-Gm-Gg: ASbGncv3UrF/yMwmdzCknPAh/QznscOnjhioj105HpowCGX6pmYiaU+QMC5gjydATnR IiLyLUXlAa7pQwJ6FDLuHxCF8fCzhT+cMFOgtNghaAIQAW3Fle0ylTlCpcW+lxC3hqTuEM91xwR 2u8LUfbI0i7Ezco1qnjk1KWEb4+z3QSRtXzKc27O6YHawDJYpTJFtMId2qI3A0I8hCOQ8L5ymqk qkkwpNYAgW3vM0wx8zK+LVcYCbV/rYvOy+wHVINVNAkYCNjVN8Kn3OkIeK5IcuWzHBd4huvav3n iD4nHqOdDeuOY7WtTMU/mpoMCRJaJWs2B7wUHv+QRDgSqIAgwsb5eja0PSjrKiAMwdgGm98fIQQ jVe73CXE9uHcnaw== X-Google-Smtp-Source: AGHT+IFm2XOGvEu+c2Vt4oKDTOhDYuX0Zc67/qbAzwRfpRIo4JlzBUdpBKcXvIOmlDkGO4s2VlIKAQ== X-Received: by 2002:a05:600c:3ba2:b0:442:dc6f:7a21 with SMTP id 5b1f17b1804b1-4533ca79d19mr100567515e9.3.1750090071100; Mon, 16 Jun 2025 09:07:51 -0700 (PDT) Received: from myrica (92.40.185.180.threembb.co.uk. [92.40.185.180]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a568b19b32sm11602270f8f.67.2025.06.16.09.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Jun 2025 09:07:50 -0700 (PDT) Date: Mon, 16 Jun 2025 17:07:52 +0100 From: Jean-Philippe Brucker To: Alyssa Ross Subject: Re: Virtio interrupt remapping Message-ID: <20250616160735.GA5171@myrica> References: <20250613181345.GA1350149@myrica> <6b661c62-c322-4f2b-8e4a-da1d5c5e48a1@gmail.com> <877c1ed9o7.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877c1ed9o7.fsf@alyssa.is> Message-ID-Hash: KGRXILOTJXWF4RUDAYGKX5RKX7YD5OEY X-Message-ID-Hash: KGRXILOTJXWF4RUDAYGKX5RKX7YD5OEY X-MailFrom: jean-philippe@linaro.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Demi Marie Obenour , Joerg Roedel , Will Deacon , Robin Murphy , virtualization@lists.linux.dev, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, devel@spectrum-os.org, Thomas Gleixner , Bjorn Helgaas , linux-pci@vger.kernel.org, eric.auger@redhat.com X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: [+Eric] On Sat, Jun 14, 2025 at 10:11:52AM +0200, Alyssa Ross wrote: > Demi Marie Obenour writes: > > > On 6/13/25 14:13, Jean-Philippe Brucker wrote: > >> Hi, > >> > >> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote: > >>> I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1], > >>> and am running into a problem. All of the current interrupt remapping > >>> drivers use __init code during initialization, and I’m not sure how to > >>> plumb the struct virtio_device * into the IOMMU initialization code. > >>> > >>> What is the proper way to do this, where “proper” means that it doesn’t > >>> do something disgusting like “stuff the virtio device in a global > >>> variable”? > >> > >> I'm not familiar at all with interrupt remapping, but I suspect a major > >> hurdle will be device probing order: the PCI subsystem probes the > >> virtio-pci transport device relatively late during boot, and the virtio > >> driver probes the virtio-iommu device afterwards, at which point we can > >> call viommu_probe() and inspect the device features and config. This can > >> be quite late in userspace if virtio and virtio-iommu get loaded as > >> modules (which distros tend to do).> > >> The way we know to hold off initializing dependent devices before the > >> IOMMU is ready is by reading the firmware tables. In devicetree the > >> "msi-parent" and "msi-map" properties point to the interrupt remapping > >> device, so by reading those Linux knows to wait for the probe of the > >> remapping device before setting up those endpoints. The ACPI VIOT > >> describes this topology as well, although at the moment it does not have > >> separate graphs for MMU and interrupts, like devicetree does (could > >> probably be added to the spec if needed, but I'm guessing the topologies > >> may be the same for a VM). If the interrupt infrastructure supports > >> probe deferral, then that's probably the way to go. > > > > I don't see any examples of probe deferral in the codebase. I think the flow with VIOT is roughly: // Scan an endpoint pci_bus_add_device() device_attach() driver_probe_device() really_probe() dev->bus->dma_configure() pci_dma_configure() acpi_dma_configure() acpi_iommu_configure_id() viot_iommu_configure() viot_dev_iommu_init() acpi_iommu_fwspec_init() iommu_fwspec_init() driver_deferred_probe_check_state() iommu ready ? 0 : -EPROBE_DEFER So if the IOMMU isn't available at this point, base/dd.c adds the device to the deferred probe list, to be retried later. Later: // Scan the IOMMU ... virtio_dev_probe() viommu_probe() iommu_device_register() add to iommu_device_list iommu->ready = true I believe after this probe completes, base/dd.c checks if dependent devices can now be probed: driver_bound() driver_deferred_probe_trigger() That should all be working and you don't need to add anything. The question is whether the interrupt core supports starting the setup of interrupt remapping in viommu_probe(), or if it needs to know of the IOMMU's config and features earlier during boot. Even if the viommu driver is builtin, those info may not be available early enough since they require PCI and virtio probe. > > Would it instead be possible to require virtio-iommu (and thus virtio) > > to be built-in rather than modules? > > It's certainly possible to have an optional feature in the kernel that > depends on a module being built in where it otherwise wouldn't have to be. Agree, no problem requiring this as a first step, but the IOMMU probe might still not be early enough. Thanks, Jean