search for: intel_iommu_add_device

This patch maps RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Currently, hypervisor sets up devices and RMRR for dom0, and dom0 also adds devices for itself via hypercall. This is obviously duplicate. In order to allow old dom0 kernels to wor...

...letions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index b9f905a55dda..b906727f5b85 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5781,78 +5781,27 @@ static bool intel_iommu_capable(enum iommu_cap cap) return false; } -static int intel_iommu_add_device(struct device *dev) +static struct iommu_device *intel_iommu_probe_device(struct device *dev) { - struct dmar_domain *dmar_domain; - struct iommu_domain *domain; struct intel_iommu *iommu; - struct iommu_group *group; u8 bus, devfn; - int ret; iommu = device_to_iommu(dev, &bus, &de...

...unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create win2k the system reboots any ideas? -- stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...v)) - return dma_direct_get_required_mask(dev); return DMA_BIT_MASK(32); } @@ -5014,7 +4973,6 @@ int __init intel_iommu_init(void) if (!has_untrusted_dev() || intel_no_bounce) swiotlb = 0; #endif - dma_ops = &intel_dma_ops; init_iommu_pm_ops(); @@ -5623,6 +5581,8 @@ static int intel_iommu_add_device(struct device *dev) dev_info(dev, "Device uses a private identity domain.\n"); } + } else { + dev->dma_ops = &intel_dma_ops; } } else { if (device_def_domain_type(dev) == IOMMU_DOMAIN_DMA) { @@ -5639,6 +5599,7 @@ static int intel_iommu_add_device(struct d...

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v3: - add Reviewed-by from Jean-Philippe Brucker on virtio patch - add Acked-by from Will Deacon on ARM SMMU patch

...; > - kfree(entry); > > -} > > - > > int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct device *dev) > > { > > struct device_domain_info *info; > > @@ -5987,7 +5978,7 @@ const struct iommu_ops intel_iommu_ops = { > > .add_device = intel_iommu_add_device, > > .remove_device = intel_iommu_remove_device, > > .get_resv_regions = intel_iommu_get_resv_regions, > > - .put_resv_regions = intel_iommu_put_resv_regions, > > + .put_resv_regions = generic_iommu_put_resv_regions, > > .apply_resv_region = intel_iommu_apply...

The patches are as follows: Patch 1: Map RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Patch 2: There is only one INCLUDE_ALL DMAR unit in system, but no restriction on whether it''s the last unit. Patch 3: Change code style of pci.c file, and add spin_unlock(...

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

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v2: - change subject prefix to "iommu: virtio: " for virtio-iommu.c driver Thierry Thierry Reding (5):

...omain, @@ -5902,6 +5916,7 @@ const struct iommu_ops intel_iommu_ops = { .aux_get_pasid = intel_iommu_aux_get_pasid, .map = intel_iommu_map, .unmap = intel_iommu_unmap, + .flush_iotlb_range = intel_iommu_flush_iotlb_range, .iova_to_phys = intel_iommu_iova_to_phys, .add_device = intel_iommu_add_device, .remove_device = intel_iommu_remove_device, diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index db7bfd4f2d20..cec728f40d9c 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -667,7 +667,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,...

Hi Pierre, thanks for your reply. I am using kernel 3.10.0-123.8.1.el7.x86_64. The kernel modul used after nodedev-detach is vfio-pci This is the output of lspci -vv after I did a virsh nodedev-detatch pci_0000_02_00_0 02:00.0 Ethernet controller: PLX Technology, Inc. Device 235e Subsystem: PLX Technology, Inc. Device 235e Control: I/O- Mem- BusMaster- SpecCycle- MemWINV-

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the third version of this patch-set. Older versions can be found here: v1: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ (Has some more introductory text) v2: https://lore.kernel.org/lkml/20200414131542.25608-1-joro at 8bytes.org/ Changes v2 -> v3: * Rebased v5.7-rc3 * Added a missing iommu_group_put() as reported by Lu Baolu. * Added a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a