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 83294E518; Fri, 13 Jun 2025 18:13:55 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id B198FE58E; Fri, 13 Jun 2025 18:13:52 +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=3.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,RCVD_IN_DNSWL_NONE,RCVD_IN_SBL_CSS, SPF_HELO_NONE autolearn=no autolearn_force=no version=4.0.1 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by atuin.qyliss.net (Postfix) with ESMTPS id C0ADBE58D for ; Fri, 13 Jun 2025 18:13:50 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-60707b740a6so3647729a12.0 for ; Fri, 13 Jun 2025 11:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1749838425; x=1750443225; 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=0INhtq8UslCI0h3j7LA2BL7iWR70QyFmUejwynW5DK0=; b=zs9Bzv+dCgSvvCqBDH3ICnrrjbWq4StDmAP8TaXheaP84LTlrQkYZ9b13k4aOghoUM 0O8cFxBY+3FCrZylOVrBtiSyQ7rf6Q+2MUBp4oKXfEwTzjKb3EkidvLiA7y5WRg4srt7 gjYpVlK8QFXDpxF8AGXtqDzt4XJO2y6fO26mIseDM2jWu9jrkStfQbA/dLPJU2hfSWcn PBnro/cwLqdnTZK3f1gVm9tqjNgq6B+50rpnNhRsUKgAkrbfkni97af29624b0xhJVh9 HfAfJv3M3eVZIk7k5g5tTYfgpGfL/Yz7HslDgBO3cn2d3gR93z/PzIIdC8DTUOlwotDT G2ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749838425; x=1750443225; 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=0INhtq8UslCI0h3j7LA2BL7iWR70QyFmUejwynW5DK0=; b=gTOAm41lM0hNN3QG/fgbz1ju9/TUrl60HKetmBxy9LVhmN/CQSXGAQqer+pPUEYoD+ /6RwwYTBlOPBUX1JZp8LE4YQGgD/yvSoxf4b4yJtF9N+eDqCYtqmXQPExhdMNETu9RhJ Jbe+pPlBCAeWMTRSe6qFG0iY4DdQwo90g1p+gdLpjTjmIKF23i2Z7tYu6hErSQ9yWxXr l13Vr80s6rxz+Mj93P84Ztpzalb/42rtNT7dsL5eu+sEoLNWhkanqS0D7Je0AsiB79vY sZjv7F/RHOdFKrDvwrln0w/IP/Ro7UoLOeiaWBj4rjhjMwIQutazBPBbZFe2i8Ha+6WA 409w== X-Forwarded-Encrypted: i=1; AJvYcCVk7O86GCDfKamuYQIhem61Zfaxfcb4ekDES9MeLCd9r7erWj0lwxDaQ+ga/uimTtT+Rpbggg==@spectrum-os.org X-Gm-Message-State: AOJu0YxtHGuoFXOPbFC8z8fJDxptygM5AOWMKXt5PvcY6I1se7mHJ9y+ sA6v5iZX8hVFG4/PTIQ+uabnS55t+DfzwRS6xJSjX8xMoxCmUISnm0eA4yLr+1poHy8= X-Gm-Gg: ASbGncs2Xr6UoN6eJhDEn8GSCQzmKZFIqtIu3t0Sgj8iKqjZvA3XNTdXERQk8fO2IJV 7NtGYYxmLqzmWG0xEwcBwQLPrmVxDAvU4CTp5uGxBljZ73o6Oh8UEbLCjOwPc+BoWIGap7icje6 uja2wTgOwiDXD6tpjImljL6JKhRqfiA/iD0grxu8ZliO2/WnKzQeDIxkZVLQhJY5EMc10T7gb3e kJHc3HH2jY21wMtBQQfufsfKQH31Y8gyt3LNQLsMpYVUVeBUrl6E6Z8DM/98v6wRkvCoqY+hHl/ oJU+nD/B2YyFNGrHLCVAutqN46g1yB6RLGFBunYkKSK9ufdyNXTnS6YKsvNoAii8WgZHg6y7TNW Rb6OO1mqPq8E= X-Google-Smtp-Source: AGHT+IE7chg7Stgbh4Yr4tdDPknvVXXUYCN1Cbm/Af0sSgXY5X2QBDtOR02WyyHHfHlz7aluSu81iw== X-Received: by 2002:a05:6402:2550:b0:5f3:857f:2b38 with SMTP id 4fb4d7f45d1cf-608d0948ae9mr218552a12.17.1749838424741; Fri, 13 Jun 2025 11:13:44 -0700 (PDT) Received: from myrica (92.40.185.95.threembb.co.uk. [92.40.185.95]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-608b4a94d18sm1502508a12.67.2025.06.13.11.13.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jun 2025 11:13:44 -0700 (PDT) Date: Fri, 13 Jun 2025 19:13:45 +0100 From: Jean-Philippe Brucker To: Demi Marie Obenour Subject: Re: Virtio interrupt remapping Message-ID: <20250613181345.GA1350149@myrica> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Message-ID-Hash: YO6UGM6LKZ2SF4UIFXTK7D457GV4WIK7 X-Message-ID-Hash: YO6UGM6LKZ2SF4UIFXTK7D457GV4WIK7 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: Joerg Roedel , Will Deacon , Robin Murphy , virtualization@lists.linux.dev, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, devel@spectrum-os.org, Alyssa Ross 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: 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. Thanks, Jean