| Message ID | cover.1657034827.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iommu: Retire bus_set_iommu() | expand |
On Tue, 2022-07-05 at 18:08 +0100, Robin Murphy wrote: > v2: https://lore.kernel.org/linux-iommu/cover.1650890638.git.robin.murphy@arm.com/ > > Hi all, > > Here's v3, now with working x86! Having finally made sense of how I > broke Intel, I've given AMD the same fix by inspection. I'm still not > 100% sure about s390, but it looks like it should probably be OK since > it seems to register an IOMMU instance for each PCI device (?!) before > disappearing into PCI hotplug code, wherein I assume we should never see > a PCI device appear without its IOMMU already registered. Yes, this is a bit unusual as our PCI architecture doesn't really have a notion of an IOMMU device only of I/O translation tables. These are then registered per PCI function. PCI functions may share I/O translation tables and thus DMA address spaces but this is not done at the moment. As Matt already mentioned we do need a small change for this patch series. Since that was still mangled in his mail for me I just replied with that using "git send-email". With Matt's patch applied I can confirm that this works fine for us and does look like a useful simplification. So feel free to add my Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
On 2022-07-05 18:08, Robin Murphy wrote: > v2: https://lore.kernel.org/linux-iommu/cover.1650890638.git.robin.murphy@arm.com/ > > Hi all, > > Here's v3, now with working x86! Having finally made sense of how I > broke Intel, I've given AMD the same fix by inspection. I'm still not > 100% sure about s390, but it looks like it should probably be OK since > it seems to register an IOMMU instance for each PCI device (?!) before > disappearing into PCI hotplug code, wherein I assume we should never see > a PCI device appear without its IOMMU already registered. > > Otherwise, the only other updates are hooking up the new host1x context > bus (noting that it now takes all of 4 lines to support a whole new bus, > yay!), and a slight tweak to make sure we keep rejecting registration of > conflicting iommu_ops rather than needlessly change that just yet. FWIW I've prepared v4, including Matt's s390 patch and some nice extra cleanups thanks to Kevin's suggestions, but have now decided to wait to rebase and send it after the upcoming merge window. If anyone's interested in the meantime, there's a preliminary branch here: https://gitlab.arm.com/linux-arm/linux-rm/-/commits/bus-set-iommu-v4 (temporarily including the host1x patch from -next to avoid breakage on arm64 as well) Thanks, Robin.
> From: Robin Murphy <robin.murphy@arm.com> > Sent: Friday, July 15, 2022 9:13 PM > > On 2022-07-05 18:08, Robin Murphy wrote: > > v2: https://lore.kernel.org/linux- > iommu/cover.1650890638.git.robin.murphy@arm.com/ > > > > Hi all, > > > > Here's v3, now with working x86! Having finally made sense of how I > > broke Intel, I've given AMD the same fix by inspection. I'm still not > > 100% sure about s390, but it looks like it should probably be OK since > > it seems to register an IOMMU instance for each PCI device (?!) before > > disappearing into PCI hotplug code, wherein I assume we should never see > > a PCI device appear without its IOMMU already registered. > > > > Otherwise, the only other updates are hooking up the new host1x context > > bus (noting that it now takes all of 4 lines to support a whole new bus, > > yay!), and a slight tweak to make sure we keep rejecting registration of > > conflicting iommu_ops rather than needlessly change that just yet. > > FWIW I've prepared v4, including Matt's s390 patch and some nice extra > cleanups thanks to Kevin's suggestions, but have now decided to wait to > rebase and send it after the upcoming merge window. If anyone's > interested in the meantime, there's a preliminary branch here: > > https://gitlab.arm.com/linux-arm/linux-rm/-/commits/bus-set-iommu-v4 > > (temporarily including the host1x patch from -next to avoid breakage on > arm64 as well) > This looks good to me.