On 30/11/16 14:08, Auger Eric wrote: > Hi Will, > > On 30/11/2016 11:37, Will Deacon wrote: >> On Wed, Nov 30, 2016 at 10:49:33AM +0100, Auger Eric wrote: >>> On 15/11/2016 14:09, Eric Auger wrote: >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
