From: Demi Marie Obenour <demiobenour@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Len Brown" <lenb@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>,
"Alyssa Ross" <hi@alyssa.is>
Cc: virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, iommu@lists.linux.dev,
x86@kernel.org, Spectrum OS Development <devel@spectrum-os.org>
Subject: Virtio-IOMMU interrupt remapping design
Date: Sun, 15 Jun 2025 14:47:15 -0400 [thread overview]
Message-ID: <a65d955c-192b-4e79-ab11-8e2af78b62af@gmail.com> (raw)
In-Reply-To: <>
[-- Attachment #1.1.1: Type: text/plain, Size: 1798 bytes --]
Virtio-IOMMU interrupt remapping turned out to be much harder than I
realized. The main problem is that interrupt remapping is set up
very early in boot. In fact, Linux calls the interrupt remapping probe
function from the APIC initialization code: x86_64_probe_apic ->
enable_IR_x2apic -> irq_remapping_prepare(). This is almost certainly
much before PCI has been initialized. Also, the order in which devices
will be initialized is not something Linux guarantees at all, which is a
problem because interrupt remapping must be initialized before drivers
start setting up interrupts. Otherwise, the interrupt remapping table
won't include entries for already-existing interrupts, and things will
either break badly, not get the benefit of interrupt remapping
security-wise, or both.
The reason I expect this doesn't cause problems for address translation
is that the IOMMU probably starts in bypass mode by default, meaning
that all DMA is permitted. If the IOMMU is only used by VFIO or
IOMMUFD, it will not be needed until userspace starts up, which is after
the IOMMU has been initialized. This isn't ideal, though, as it means
that kernel drivers operate without DMA protection.
Is a paravirtualized IOMMU with interrupt remapping something that makes
sense? Absolutely! However, the IOMMU should be considered a platform
device that must be initialized very early in boot. Using virtio-IOMMU
with MMIO transport as the interface might be a reasonable option, but
the IOMMU needs to be enumerated via ACPI, device tree, or kernel
command line argument. This allows it to be brought up before anything
capable of DMA is initialized.
Is this the right path to go down? What do others think about this?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2025-06-15 18:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-15 18:47 Demi Marie Obenour [this message]
2025-06-16 13:20 ` Virtio-IOMMU interrupt remapping design Jason Gunthorpe
2025-06-16 16:53 ` Demi Marie Obenour
2025-06-16 17:33 ` Jason Gunthorpe
2025-06-17 19:44 ` Michael S. Tsirkin
2025-06-17 19:57 ` Jason Gunthorpe
2025-06-17 20:01 ` Michael S. Tsirkin
2025-06-17 23:03 ` Jason Gunthorpe
2025-06-17 19:46 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a65d955c-192b-4e79-ab11-8e2af78b62af@gmail.com \
--to=demiobenour@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=devel@spectrum-os.org \
--cc=eperezma@redhat.com \
--cc=hi@alyssa.is \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=joro@8bytes.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mst@redhat.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).