[RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: robin.murphy@arm.com (Robin Murphy)
Date: 2016-11-30 14:42:14
Also in:
kvm, linux-iommu, lkml
On 30/11/16 14:08, Auger Eric wrote:
Hi Will, On 30/11/2016 11:37, Will Deacon wrote:quoted
On Wed, Nov 30, 2016 at 10:49:33AM +0100, Auger Eric wrote:quoted
On 15/11/2016 14:09, Eric Auger wrote:quoted
Following LPC discussions, we now report reserved regions through iommu-group sysfs reserved_regions attribute file. Reserved regions are populated through the IOMMU get_resv_region callback (former get_dm_regions), now implemented by amd-iommu, intel-iommu and arm-smmu. The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an IOMMU_RESV_NOMAP reserved region. arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and 1MB large) and the PCI host bridge windows. The series integrates a not officially posted patch from Robin: "iommu/dma: Allow MSI-only cookies". This series currently does not address IRQ safety assessment.I will respin this series taking into account Joerg's comment. Does anyone have additional comments or want to put forward some conceptual issues with the current direction and with this implementation? As for the IRQ safety assessment, in a first step I would propose to remove the IOMMU_CAP_INTR_REMAP from arm-smmus and consider the assignment as unsafe. Any objection?Well, yeah, because it's perfectly safe with GICv3.Well except if you have an MSI controller in-between the device and the sMMU (typically embedded in the host bridge). Detecting this situation is not straightforward; hence my proposal.
That's not the GICv3 (ITS) case, though, and either way it's irrelevant to the "safety" aspect in question; the fact that writes to the ITS carry sideband signals which disambiguate and isolate MSIs has nothing to do with whether that write undergoes address translation along the way. It's also not legacy INTx, and the fact that we have to pretend the SMMU provides MSI isolation in order to make things work with INTx is an entirely separate piece of brokenness I've raised several times before. I more than anyone would love to remove IOMMU_CAP_INTR_REMAP from the SMMU drivers yesterday, but doing so breaks the existing use-case on ARM unless we actually fix that aspect of VFIO first (I did look into it once, but it seemed way beyond my comprehension at the time). Robin.