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 153C211CC5; Sat, 14 Jun 2025 08:12:08 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 7658D11C7A; Sat, 14 Jun 2025 08:12:05 +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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-b1-smtp.messagingengine.com (fout-b1-smtp.messagingengine.com [202.12.124.144]) by atuin.qyliss.net (Postfix) with ESMTPS id 24DC411CBB for ; Sat, 14 Jun 2025 08:12:03 +0000 (UTC) Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id ADCE911400BF; Sat, 14 Jun 2025 04:11:59 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Sat, 14 Jun 2025 04:12:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1749888719; x=1749975119; bh=JwG6ow84k0 7PawGfenasYl7lKn5ZP5JhzPigKUfXkws=; b=gkyXv30GagEsyTHnObiMwLOBwy kUma1xRlwwVl0J2YHVsgwj4KBhgSSn/7edLwh04ieoylyxOxCcc/6tO/78n381Tr Pn4BAhI68BdhHP5ZRurhLBuXlZlFfGHmhm09g60ulaqciOZnqct448yKAzsxl8G0 fJ1303El+rQ+xhSk+btlFjI7fRAK6UeAZvDswa1MD5XcNnnBFRlSiptaoZ57iR63 JL4rCP4N+OMdic8SOzRcB1HGAngKW0QO6DE4UkXKpvpD3dsZAFw/aYLJoTLlAaCI +y7fi3/ns+qFL+XW2xByHaUxEP/DXTh0jsfD8SeCtZcRwucprZc/EGqvvCJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1749888719; x=1749975119; bh=JwG6ow84k07PawGfenasYl7lKn5ZP5JhzPi gKUfXkws=; b=hLhlQXtNzT9DaOfQTpCuB498ZYvUCyebN6AixnScNcs7jjDVK31 BV03uu4/vnON2lonpM2+dbHua0yUO5ADbB/61wnQElEYBeIjpqVmJ519vt/o3YBG UN28qj8ch1pMo0PADgjaEYaOoFCQrODsK4uyrDWS5asPPJbsUmmfKLqwimv3P/vR VHv347uTtD93aK2kY0/ffH4zIkhDCMqZYv5/HPhcP7/PNp5B/mnG0mybJZ5HRVN5 uNmecII8qXky1OTbDso+esPrghAc/nUCc02tBcWfops8Gkyv+1VQ7xAWKhmDJfkJ zKMSan20EDVaD6mxae5DhQ6wSmIPmNSrm9w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddvtdefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesghdtreertddtjeen ucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecugg ftrfgrthhtvghrnhepteehvedugfejgfehhfeijeduleekleejgedvkeeuuefhhfegvdev feetveegteeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhephhhisegrlhihshhsrgdrihhspdhnsggprhgtphhtthhopeduvddpmhhouggvpehs mhhtphhouhhtpdhrtghpthhtohepjhhorhhoseeksgihthgvshdrohhrghdprhgtphhtth hopehrohgsihhnrdhmuhhrphhhhiesrghrmhdrtghomhdprhgtphhtthhopeguvghmihho sggvnhhouhhrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepsghhvghlghgrrghssehgoh hoghhlvgdrtghomhdprhgtphhtthhopeifihhllheskhgvrhhnvghlrdhorhhgpdhrtghp thhtohepjhgvrghnqdhphhhilhhiphhpvgeslhhinhgrrhhordhorhhgpdhrtghpthhtoh epthhglhigsehlihhnuhhtrhhonhhigidruggvpdhrtghpthhtohepihhomhhmuheslhhi shhtshdrlhhinhhugidruggvvhdprhgtphhtthhopehvihhrthhurghlihiirghtihhonh eslhhishhtshdrlhhinhhugidruggvvh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Jun 2025 04:11:58 -0400 (EDT) Received: by sf.qyliss.net (Postfix, from userid 1000) id 465FF2462C4EE; Sat, 14 Jun 2025 10:11:56 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour , Jean-Philippe Brucker Subject: Re: Virtio interrupt remapping In-Reply-To: <6b661c62-c322-4f2b-8e4a-da1d5c5e48a1@gmail.com> References: <20250613181345.GA1350149@myrica> <6b661c62-c322-4f2b-8e4a-da1d5c5e48a1@gmail.com> Date: Sat, 14 Jun 2025 10:11:52 +0200 Message-ID: <877c1ed9o7.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: E23WSPFZXV76FAYKS44M6U7QGCWQMO6Q X-Message-ID-Hash: E23WSPFZXV76FAYKS44M6U7QGCWQMO6Q X-MailFrom: hi@alyssa.is 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: 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 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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Demi Marie Obenour writes: > On 6/13/25 14:13, Jean-Philippe Brucker wrote: >> Hi, >>=20 >> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote: >>> I=E2=80=99m 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=E2=80=99m not sure= how to >>> plumb the struct virtio_device * into the IOMMU initialization code. >>> >>> What is the proper way to do this, where =E2=80=9Cproper=E2=80=9D means= that it doesn=E2=80=99t >>> do something disgusting like =E2=80=9Cstuff the virtio device in a glob= al >>> variable=E2=80=9D? >>=20 >> 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).>=20 >> 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. 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaE0uyAAKCRBbRZGEIw/w op9sAQCBEK39AU0uG82apXlVJycAj+vYG4hJGp4AKjRa1oUInAD8DE0FHvSy5oob 9ZDBmNcIqygQjmlHb2pkCf+AglE69gU= =uvU/ -----END PGP SIGNATURE----- --=-=-=--