search for: dummy_device_domain_info

On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote: > OK, so for intel, it seems that it's enough to set > pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO; > for the device. Yes, currently. Although that's vile. In fact what we *want* to happen is for the intel-iommu code simply to decline to provide DMA ops for this device, and let it fall back to the swiotlb or no-op DMA ops, as appropriate. As it is, we have the intel-iommu DMA ops *uncon...

On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote: > OK, so for intel, it seems that it's enough to set > pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO; > for the device. Yes, currently. Although that's vile. In fact what we *want* to happen is for the intel-iommu code simply to decline to provide DMA ops for this device, and let it fall back to the swiotlb or no-op DMA ops, as appropriate. As it is, we have the intel-iommu DMA ops *uncon...

On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote: > I see work-arounds for broken IOMMUs but not for > individual devices. Could you point me to a more specific > example? I think the closest example is probably quirk_ioat_snb_local_iommu(). If we see this particular device, we *know* what the topology actually looks like. We check the hardware setup, and if we're *not*

On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote: > I see work-arounds for broken IOMMUs but not for > individual devices. Could you point me to a more specific > example? I think the closest example is probably quirk_ioat_snb_local_iommu(). If we see this particular device, we *know* what the topology actually looks like. We check the hardware setup, and if we're *not*

...e work-arounds for broken IOMMUs but not for > > individual devices. Could you point me to a more specific > > example? > > I think the closest example is probably quirk_ioat_snb_local_iommu(). OK, so for intel, it seems that it's enough to set pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO; for the device. Do I have to poke at each iommu implementation to find a way to do this, or is there some way to do it portably? > If we see this particular device, we *know* what the topology actually > looks like. We check the hardware setup, and if we're *not* being told > the tr...

...-- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2794,17 +2794,6 @@ static int __init si_domain_init(int hw) return 0; } -static int identity_mapping(struct device *dev) -{ - struct device_domain_info *info; - - info = dev->archdata.iommu; - if (info && info != DUMMY_DEVICE_DOMAIN_INFO && info != DEFER_DEVICE_DOMAIN_INFO) - return (info->domain == si_domain); - - return 0; -} - static int domain_add_dev_info(struct dmar_domain *domain, struct device *dev) { struct dmar_domain *ndomain; @@ -3461,12 +3450,6 @@ static struct dmar_domain *get_private_domain_for_dev(st...

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the