From: "Michael S. Tsirkin" <mst@redhat.com>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: "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>,
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: Re: Virtio-IOMMU interrupt remapping design
Date: Tue, 17 Jun 2025 15:46:12 -0400 [thread overview]
Message-ID: <20250617154524-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <a65d955c-192b-4e79-ab11-8e2af78b62af@gmail.com>
On Sun, Jun 15, 2025 at 02:47:15PM -0400, Demi Marie Obenour wrote:
> 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)
The project for this discussion is also virtio-comment,
this ML is for driver work.
prev parent reply other threads:[~2025-06-17 19:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-15 18:47 Virtio-IOMMU interrupt remapping design Demi Marie Obenour
2025-06-16 13:20 ` 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 [this message]
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=20250617154524-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=demiobenour@gmail.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.