- 02 Jun, 2015 1 commit
-
-
Joerg Roedel authored
This reverts commit 5fc872c7 . The DMA-API does not strictly require that the memory returned by dma_alloc_coherent is zeroed out. For that another function (dma_zalloc_coherent) should be used. But all other x86 DMA-API implementation I checked zero out the memory, so that some drivers rely on it and break when it is not. It seems the (driver-)world is not yet ready for this change, so revert it. Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
- 02 Apr, 2015 9 commits
-
-
Joerg Roedel authored
When a default page-size for given level should be mapped, the level encoding must be 0 rather than 7. This fixes an issue seen on IOMMUv2 hardware, where this encoding is enforced. Tested-by:
Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by:
-
Joerg Roedel authored
Now that fetch_pte returns the page-size of the pte, this function can be optimized too. Tested-by:
-
Joerg Roedel authored
Now that fetch_pte returns the page-size of the pte, the call in this function can also be optimized a little bit. Tested-by:
-
Joerg Roedel authored
Now that fetch_pte returns the page-size of the pte, this function can be optimized a lot. Tested-by:
-
Joerg Roedel authored
Extend the fetch_pte function to also return the page-size that is mapped by the returned pte. Tested-by:
-
Joerg Roedel authored
Add code to allocate memory from the contiguous memory allocator to support coherent allocations larger than 8MB. Tested-by:
-
Joerg Roedel authored
Don't explicitly add __GFP_ZERO to the allocator flags. Leave this up to the caller. Tested-by:
-
Joerg Roedel authored
Detaching a device from its domain at this event is problematic for several reasons: * The device might me in an alias group and detaching it will also detach all other devices in the group. This removes valid DMA mappings from the other devices causing io-page-faults and lets these devices fail. * Devices might have unity mappings specified by the IVRS table. These mappings are required for the device even when no device driver is attached. Detaching the device from its domain in driver unbind will also remove these unity mappings. This patch removes the handling of the BUS_NOTIFY_UNBOUND_DRIVER event to prevent these issues and align it better with the behavior of the VT-d driver. Tested-by:
-
Joerg Roedel authored
Use the new device-notifier event instead of the old BUS_NOTIFY_DEL_DEVICE to make sure the device driver had a chance to uninit the device before all its mappings are teared down. Tested-by:
-
- 31 Mar, 2015 1 commit
-
-
Joerg Roedel authored
Implement the new iommu-ops function pointers and remove the obsolete domain_init and domain_destroy functions. Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
- 04 Feb, 2015 2 commits
-
-
Quentin Lambert authored
This patch was produced using Coccinelle. A simplified version of the semantic patch is: @r exists@ identifier f; local idexpression u8 x; identifier xname; @@ f(...) { ...when any ( x@xname = 1; | x@xname = 0; ) ...when any } @bad exists@ identifier r.f; local idexpression u8 r.x expression e1 != {0, 1}, e2; @@ f(...) { ...when any ( x = e1; | x + e2 ) ...when any } @depends on !bad@ identifier r.f; local idexpression u8 r.x; identifier r.xname; @@ f(...) { ... ++ bool xname; - int xname; <... ( x = - 1 + true | x = - -1 + false ) ...> } Signed-off-by:Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by:
-
Joerg Roedel authored
The AMD address is dead for a long time already, replace it with a working one. Signed-off-by:
-
- 15 Jan, 2015 1 commit
-
-
Jiang Liu authored
Simplify irq_remapping code by killing irq_remapping_supported() and related interfaces. Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490 , so assume an signed-off from Joerg. Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by:
Joerg Roedel <joro@8bytes.org> Cc: Tony Luck <tony.luck@intel.com> Cc: iommu@lists.linux-foundation.org Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Rientjes <rientjes@google.com> Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Richard Weinberger <richard@nod.at> Cc: Oren Twaig <oren@scalemp.com> Link: http://lkml.kernel.org/r/1420615903-28253-14-git-send-email-jiang.liu@linux.intel.com Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 16 Dec, 2014 1 commit
-
-
Jiang Liu authored
Use helpers to access irq_cfg data structure associated with IRQ, instead of accessing irq_data->chip_data directly. Later we can rewrite those helpers to support hierarchy irqdomain. Signed-off-by:
-
- 14 Nov, 2014 1 commit
-
-
Will Deacon authored
Some versions of GCC get unduly upset when confronted with a switch that doesn't explicitly handle all cases of an enum, despite having an implicit default case following the actualy switch statement: drivers/iommu/amd_iommu.c: In function 'amd_iommu_capable': >> drivers/iommu/amd_iommu.c:3409:2: warning: enumeration value 'IOMMU_CAP_NOEXEC' not handled in switch [-Wswitch] switch (cap) { This patch adds a case for IOMMU_CAP_NOEXEC to the amd IOMMU driver to remove this warning. Cc: Joerg Roedel <jroedel@suse.de> Signed-off-by:Will Deacon <will.deacon@arm.com>
-
- 04 Nov, 2014 1 commit
-
-
Olav Haugan authored
Mapping and unmapping are more often than not in the critical path. map_sg allows IOMMU driver implementations to optimize the process of mapping buffers into the IOMMU page tables. Instead of mapping a buffer one page at a time and requiring potentially expensive TLB operations for each page, this function allows the driver to map all pages in one go and defer TLB maintenance until after all pages have been mapped. Additionally, the mapping operation would be faster in general since clients does not have to keep calling map API over and over again for each physically contiguous chunk of memory that needs to be mapped to a virtually contiguous region. Signed-off-by:
Olav Haugan <ohaugan@codeaurora.org> Signed-off-by:
-
- 25 Sep, 2014 4 commits
-
-
Yijing Wang authored
Commit 71054d88 ("x86, hpet: Introduce x86_msi_ops.setup_hpet_msi") introduced x86_msi_ops.setup_hpet_msi to setup hpet MSI irq when irq remapping enabled. This caused a regression of hpet MSI irq remapping. Original code flow before commit 71054d88: hpet_setup_msi_irq() arch_setup_hpet_msi() setup_hpet_msi_remapped() remap_ops->setup_hpet_msi() alloc_irte() msi_compose_msg() hpet_msi_write() ... Current code flow after commit 71054d88 : hpet_setup_msi_irq() x86_msi.setup_hpet_msi() setup_hpet_msi_remapped() intel_setup_hpet_msi() alloc_irte() Currently, we only call alloc_irte() for hpet MSI, but do not composed and wrote its msg... Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
-
Alex Williamson authored
For a PCI device, aliases from the IVRS table won't be populated into dma_alias_devfn until after iommu_init_device() is called on each device. We therefore want to split init_iommu_group() to be called from a separate loop immediately following. Signed-off-by:
-
Maurizio Lombardi authored
under low memory conditions, alloc_pte() may return a NULL pointer. iommu_map_page() does not check it and will panic the system. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
-
Joerg Roedel authored
Signed-off-by:
-
- 26 Aug, 2014 4 commits
-
-
Joerg Roedel authored
This reference count is not used anymore, as all devices in an alias group are now attached and detached together. Signed-off-by: -
Joerg Roedel authored
Change tha device attach and detach semantic to apply to all devices in an alias group. This means all devices in an alias group are now attached and detached at the same time. Signed-off-by: -
Joerg Roedel authored
Some broken devices might use any request-id from the alias group, so we need to set a DTE entry for every device in there. This patch adds creation of those lists. Signed-off-by: -
Joerg Roedel authored
The struct is only used there, so it doesn't need to be in the header file. Signed-off-by:
-
- 18 Aug, 2014 1 commit
-
-
Joerg Roedel authored
When multiple devices are detached in __detach_device, they are also removed from the domains dev_list. This makes it unsafe to use list_for_each_entry_safe, as the next pointer might also not be in the list anymore after __detach_device returns. So just repeatedly remove the first element of the list until it is empty. Cc: stable@vger.kernel.org Tested-by:
Marti Raudsepp <marti@juffo.org> Signed-off-by:
-
- 07 Jul, 2014 1 commit
-
-
Thierry Reding authored
This structure is read-only data and should never be modified. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
- 04 Jul, 2014 3 commits
-
-
Alex Williamson authored
AMD-Vi support for IOMMU sysfs. This allows us to associate devices with a specific IOMMU device and examine the capabilities and features of that IOMMU. The AMD IOMMU is hosted on and actual PCI device, so we make that device the parent for the IOMMU class device. This initial implementaiton exposes only the capability header and extended features register for the IOMMU. # find /sys | grep ivhd /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:00.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:02.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:04.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:09.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:11.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:12.0 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:12.2 /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:13.0 ... /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/power /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/power/control ... /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/device /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/subsystem /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu/cap /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu/features /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/uevent /sys/class/iommu/ivhd0 Signed-off-by:
-
Alex Williamson authored
The common iommu_group_get_for_dev() allows us to greatly simplify our group lookup for a new device. Also, since we insert IVRS aliases into the PCI DMA alias quirks, we should alway come up with the same results as the existing code. Signed-off-by:
-
Alex Williamson authored
AMD-Vi already has a concept of an alias provided via the IVRS table. Now that PCI-core also understands aliases, we need to incorporate both aspects when programming the IOMMU. IVRS is generally quite reliable, so we continue to prefer it when an alias is present. For cases where we have an IVRS alias that does not match the PCI alias or where PCI does not report an alias, report the mismatch to allow us to collect more quirks and dynamically incorporate the alias into the device alias quirks where possible. This should allow AMD-Vi to work with devices like Marvell and Ricoh with DMA function alias quirks unknown to the BIOS. Signed-off-by:
-
- 30 May, 2014 1 commit
-
-
Joerg Roedel authored
Fix two compile warnings about unused variables introduced by commit ecef115d . Reported-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
- 26 May, 2014 1 commit
-
-
Vaughan Cao authored
amd_iommu_rlookup_table[devid] != NULL is already guaranteed by check_device called before, it's fine to attach device at this point. Signed-off-by:
Vaughan Cao <vaughan.cao@oracle.com> Signed-off-by:
-
- 13 May, 2014 1 commit
-
-
Alex Williamson authored
An apparent cut and paste error prevents the correct flags from being set on the alias device resulting in MSI on conventional PCI devices failing to work. This also produces error events from the IOMMU like: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00] Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to use MSI interrupts. Signed-off-by:
-
- 24 Mar, 2014 1 commit
-
-
Suravee Suthikulpanit authored
In reality, the spec can only support 16-bit PASID since INVALIDATE_IOTLB_PAGES and COMPLETE_PPR_REQUEST commands only allow 16-bit PASID. So, we updated the PASID_MASK accordingly and invoke BUG_ON if the hardware is reporting PASmax more than 16-bit. Besides, max PASID is defined as ((2^(PASmax+1)) - 1). The current does not determine this correctly. Signed-off-by:
Jay Cornwall <Jay.Cornwall@amd.com> Signed-off-by:
-
- 04 Mar, 2014 1 commit
-
-
Jay Cornwall authored
This patch corrects the PASID format in the INVALIDATE_IOTLB_PAGES command, which was caused by incorrect information in the AMD IOMMU Architectural Specification v2.01 document. Incorrect format: cmd->data[0][16:23] = PASID[7:0] cmd->data[1][16:27] = PASID[19:8] Correct format: cmd->data[0][16:23] = PASID[15:8] cmd->data[1][16:23] = PASID[7:0] However, this does not affect the IOMMUv2 hardware implementation, and has been corrected since version 2.02 of the specification (available through AMD NDA). Signed-off-by:
-
- 07 Jan, 2014 1 commit
-
-
Yijing Wang authored
Use PCI standard marco dev_is_pci() instead of directly compare pci_bus_type to check whether it is pci device. Signed-off-by:
-
- 14 Aug, 2013 1 commit
-
-
Radmila Kompová authored
Detected by cppcheck. Signed-off-by:
Kamil Dudka <kdudka@redhat.com> Signed-off-by:
-
- 23 Jun, 2013 1 commit
-
-
Alex Williamson authored
If we use a large mapping, the expectation is that only unmaps from the first pte in the superpage are supported. Unmaps from offsets into the superpage should fail (ie. return zero sized unmap). In the current code, unmapping from an offset clears the size of the full mapping starting from an offset. For instance, if we map a 16k physically contiguous range at IOVA 0x0 with a large page, then attempt to unmap 4k at offset 12k, 4 ptes are cleared (12k - 28k) and the unmap returns 16k unmapped. This potentially incorrectly clears valid mappings and confuses drivers like VFIO that use the unmap size to release pinned pages. Fix by refusing to unmap from offsets into the page. Signed-off-by:
-
- 20 Jun, 2013 2 commits
-
-
Joerg Roedel authored
The IOMMU pagetables can have up to 6 levels, but the code in free_pagetable() only releases the first 3 levels. Fix this leak by releasing all levels. Reported-by:
-
Alex Williamson authored
If a device is multifunction and does not have ACS enabled then we assume that the entire package lacks ACS and use function 0 as the base of the group. The PCIe spec however states that components are permitted to implement ACS on some, none, or all of their applicable functions. It's therefore conceivable that function 0 may be fully independent and support ACS while other functions do not. Instead use the lowest function of the slot that does not have ACS enabled as the base of the group. This may be the current device, which is intentional. So long as we use a consistent algorithm, all the non-ACS functions will be grouped together and ACS functions will get separate groups. Signed-off-by:
-
