| Message ID | 797c70d255f946c4d631f2ffc67f277cfe0cb97c.1647624084.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | thunderbolt: Make iommu_dma_protection more accurate | expand |
On Fri, Mar 18, 2022 at 05:42:57PM +0000, Robin Murphy wrote: > VT-d's dmar_platform_optin() actually represents a combination of > properties fairly well standardised by Microsoft as "Pre-boot DMA > Protection" and "Kernel DMA Protection"[1]. As such, we can provide > interested consumers with an abstracted capability rather than > driver-specific interfaces that won't scale. We name it for the former > aspect since that's what external callers are most likely to be > interested in; the latter is for the IOMMU layer to handle itself. > > Also use this as an opportunity to draw a line in the sand and add a > new interface so as not to introduce any more callers of iommu_capable() > which I also want to get rid of. For now it's a quick'n'dirty wrapper > function, but will evolve to subsume the internal interface in future. > > [1] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-kernel-dma-protection > > Suggested-by: Christoph Hellwig <hch@lst.de> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> I can't really think of a way in which I suggested this, but it does looks like a good interface: Reviewed-by: Christoph Hellwig <hch@lst.de>
On 2022-03-22 09:14, Christoph Hellwig wrote: > On Fri, Mar 18, 2022 at 05:42:57PM +0000, Robin Murphy wrote: >> VT-d's dmar_platform_optin() actually represents a combination of >> properties fairly well standardised by Microsoft as "Pre-boot DMA >> Protection" and "Kernel DMA Protection"[1]. As such, we can provide >> interested consumers with an abstracted capability rather than >> driver-specific interfaces that won't scale. We name it for the former >> aspect since that's what external callers are most likely to be >> interested in; the latter is for the IOMMU layer to handle itself. >> >> Also use this as an opportunity to draw a line in the sand and add a >> new interface so as not to introduce any more callers of iommu_capable() >> which I also want to get rid of. For now it's a quick'n'dirty wrapper >> function, but will evolve to subsume the internal interface in future. >> >> [1] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-kernel-dma-protection >> >> Suggested-by: Christoph Hellwig <hch@lst.de> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > I can't really think of a way in which I suggested this, but it does > looks like a good interface: Well, you were the first to say it should be abstracted[1], and since my initial thought that it could be hidden completely didn't pan out, I felt I should give you credit for being right all along :) > Reviewed-by: Christoph Hellwig <hch@lst.de> Thanks! Robin. [1] https://lore.kernel.org/linux-iommu/YjDDUUeZ%2FdvUZoDN@infradead.org/
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 0c7975848972..20d8e1f60068 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4817,6 +4817,8 @@ static bool intel_iommu_capable(enum iommu_cap cap) return domain_update_iommu_snooping(NULL); if (cap == IOMMU_CAP_INTR_REMAP) return irq_remapping_enabled == 1; + if (cap == IOMMU_CAP_PRE_BOOT_PROTECTION) + return dmar_platform_optin(); return false; } diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 4a25f8241207..e16d54e15fee 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -107,6 +107,8 @@ enum iommu_cap { transactions */ IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */ IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */ + IOMMU_CAP_PRE_BOOT_PROTECTION, /* Firmware says it used the IOMMU for + DMA protection and we should too */ }; /* These are the possible reserved region types */ @@ -1042,6 +1044,11 @@ static inline size_t iommu_map_sgtable(struct iommu_domain *domain, return iommu_map_sg(domain, iova, sgt->sgl, sgt->orig_nents, prot); } +static inline bool dev_iommu_capable(struct device *dev, enum iommu_cap cap) +{ + return device_iommu_mapped(dev) && iommu_capable(dev->bus, cap); +} + #ifdef CONFIG_IOMMU_DEBUGFS extern struct dentry *iommu_debugfs_dir; void iommu_debugfs_setup(void);
VT-d's dmar_platform_optin() actually represents a combination of properties fairly well standardised by Microsoft as "Pre-boot DMA Protection" and "Kernel DMA Protection"[1]. As such, we can provide interested consumers with an abstracted capability rather than driver-specific interfaces that won't scale. We name it for the former aspect since that's what external callers are most likely to be interested in; the latter is for the IOMMU layer to handle itself. Also use this as an opportunity to draw a line in the sand and add a new interface so as not to introduce any more callers of iommu_capable() which I also want to get rid of. For now it's a quick'n'dirty wrapper function, but will evolve to subsume the internal interface in future. [1] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-kernel-dma-protection Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- v2: New patch drivers/iommu/intel/iommu.c | 2 ++ include/linux/iommu.h | 7 +++++++ 2 files changed, 9 insertions(+)