[git pull] IOMMU Updates for Linux v3.15
Hi Linus,
The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c:
Linux 3.14 (2014-03-30 20:40:15 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-updates-v3.15
for you to fetch changes up to e172b81222548b856ecbe59b305d2cb733d512c4:
Merge branches 'iommu/fixes', 'arm/smmu', 'x86/amd', 'arm/omap',
'arm/shmobile' and 'x86/vt-d' into next (2014-04-02 19:13:12 +0200)
IOMMU Upates for Linux v3.15
This time a few more updates queued up.
* Rework VT-d code to support ACPI devices
* Improvements for memory and PCI hotplug support
in the VT-d driver
* Device-tree support for OMAP IOMMU
* Convert OMAP IOMMU to use devm_* interfaces
* Fixed PASID support for AMD IOMMU
* Other random cleanups and fixes for OMAP, ARM-SMMU
and SHMOBILE IOMMU
Most of the changes are in the VT-d driver because some rework was
necessary for better hotplug and ACPI device support.
Andreas Herrmann (3):
iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS
iommu/arm-smmu: support buggy implementations with secure cfg accesses
documentation/iommu: update description of ARM System MMU binding
Dan Carpenter (1):
iommu/vt-d: returning free pointer in get_domain_for_dev()
David Woodhouse (39):
iommu/vt-d: Clean up size handling for intel_iommu_unmap()
iommu/vt-d: Clean up and fix page table clear/free behaviour
iommu/vt-d: Honour intel_iommu=sp_off for non-VMM domains
iommu/vt-d: Be less pessimistic about domain coherency where possible
iommu/vt-d: Add ACPI namespace device reporting structures
iommu/vt-d: Parse ANDD records
iommu/vt-d: Allocate space for ACPI devices
iommu/vt-d: Change scope lists to struct device, bus, devfn
iommu/vt-d: Add ACPI devices into dmaru-devices[] array
iommu/vt-d: Make iommu_dummy() take struct device instead of struct
pci_dev
iommu/vt-d: Make dmar_insert_dev_info() take struct device instead of
struct pci_dev
iommu/vt-d: Use struct device in device_domain_info, not struct pci_dev
iommu/vt-d: Pass iommu to domain_context_mapping_one() and
iommu_support_dev_iotlb()
iommu/vt-d: Stop dmar_insert_dev_info() freeing domains on losing race
iommu/vt-d: use dmar_insert_dev_info() from dma_add_dev_info()
iommu/vt-d: Use domain_remove_one_dev_info() in domain_add_dev_info()
error path
iommu/vt-d: Always store iommu in device_domain_info
iommu/vt-d: Simplify iommu check in domain_remove_one_dev_info()
iommu/vt-d: Remove device_to_iommu() call from domain_remove_dev_info()
iommu/vt-d: Store PCI segment number in struct intel_iommu
iommu/vt-d: Remove segment from struct device_domain_info()
iommu/vt-d: Make identity_mapping() take struct device not struct pci_dev
iommu/vt-d: Make device_to_iommu() cope with non-PCI devices
iommu/vt-d: Make domain_context_mapp{ed,ing}() take struct device
iommu/vt-d: Make get_domain_for_dev() take struct device
iommu/vt-d: Handle RMRRs for non-PCI devices
iommu/vt-d: Make iommu_should_identity_map() take struct device
iommu/vt-d: Make get_valid_domain_for_dev() take struct device
iommu/vt-d: Remove some pointless to_pci_dev() calls
iommu/vt-d: Rename 'hwdev' variables to 'dev' now that that's the norm
iommu/vt-d: Make domain_remove_one_dev_info() take struct device
iommu/vt-d: Make domain_add_dev_info() take struct device
iommu/vt-d: Remove pdev from iommu_no_mapping()
iommu/vt-d: Remove pdev from intel_iommu_attach_device()
iommu/vt-d: Remove to_pci_dev() in intel_map_page()
iommu/vt-d: Finally enable translation for non-PCI devices
iommu/vt-d: Include ACPI devices in iommu=pt
iommu/vt-d: Only call dmar_acpi_dev_scope_init() if DRHD units present
iommu/vt-d: Fix error handling in ANDD processing
Florian Vaussard (3):
iommu/omap: Allow enable/disable even without pdata
Documentation: dt: add OMAP iommu bindings
iommu/omap: Add devicetree support
Jay Cornwall (1):
iommu/amd: Fix PASID format in INVALIDATE_IOTLB_PAGES command
Jiang Liu (17):
iommu/vt-d: Avoid double free of g_iommus on error recovery path
iommu/vt-d: Avoid caching stale domain_device_info and fix memory leak
iommu/vt-d: Avoid caching stale domain_device_info when hot-removing PCI
device
iommu/vt-d: Factor out dmar_alloc_dev_scope() for later reuse
iommu/vt-d: Move private structures and variables into intel-iommu.c
iommu/vt-d: Simplify function get_domain_for_dev()
iommu/vt-d: Free resources if failed to create domain for PCIe endpoint
iommu/vt-d: Reduce duplicated code to handle
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. These two levels exist in the form of the DMA-API and the IOMMU-API. In fact, the IOMMU-API was created to provide a way to drivers to specifiy the IOVA-PHYS mappings on its own. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed ? The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hello, I'm sorry for a delay, I've got back from my holidays and I'm still busy trying to get thought all the emails. On 2014-03-17 23:44, Laurent Pinchart wrote: Hi Suman and Sakari, On Monday 17 March 2014 14:58:24 Suman Anna wrote: On 03/16/2014 04:54 PM, Sakari Ailus wrote: On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. Right, although you might not always have to manage the VA space in that case. Anyway, if your driver needs to manage the VA space for the firmware, it should be able to manage the VA space for the buffers using the same IOMMU API. I've already seen some use cases which require to give a client device limited access to DMA mapping IOMMU related structures. If we agree on API, I see no problems to add such calls to dma-mapping. However in the most common case I would like to hide the presence of IOMMU from the client device at all. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed? Can this be done through iommu_domain_set_attr? But that means the
Re: [PATCH] iommu-groups: Add list_head for iommu groups
On Fri, 2014-04-04 at 11:12 +0530, Ritesh Harjani wrote:
Hi All,
Please find the below patch and let me know your suggestions on this.
With this patch iommu groups can be linked and iommu driver will
get to know which all iommu groups belongs to a particular iommu device.
Each iommu device might have multiple iommu groups,
with each group populated with many devices. With
this configuration, iommu driver may require a list
of iommu groups belonging to each iommu device.
Add list_head struct entry in iommu_group.
Signed-off-by: Ritesh Harjani ritesh.harj...@gmail.com
---
drivers/iommu/iommu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index efc..70588dc 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -36,6 +36,10 @@ static struct ida iommu_group_ida;
static struct mutex iommu_group_mutex;
struct iommu_group {
+ struct list_head list; /* lower level iommu driver structure
+* may require list of iommu groups
+* belonging to that iommu device.
+*/
To have a list would require locking to manage that list, but you seem
to imply that the iommu driver would be managing this list... but there
might be multiple iommu drivers in a single system. Groups are
currently independent of each other by design, trying to manage them in
a list defeats that. There is also no example provided here of why we
would need or even want to do this. Thanks,
Alex
struct kobject kobj;
struct kobject *devices_kobj;
struct list_head devices;
--
1.8.1.3
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH v2 1/2] pci: Create PCIe requester ID interface
On Thu, Apr 3, 2014 at 8:51 PM, Alex Williamson alex.william...@redhat.com wrote: On Thu, 2014-04-03 at 15:48 -0600, Bjorn Helgaas wrote: [+cc George] On Fri, Aug 2, 2013 at 10:59 AM, Alex Williamson alex.william...@redhat.com wrote: ... Great! I'm still trying to figure out how to handle the quirk around Intel PCI-to-PCI bridge on the root complex as just another quirk. I respin another version once I have that worked out. Thanks, Is anything happening here? These buggy IOMMU/DMA source problems, e.g., [1], have been lingering a long time, and I don't know if we're stuck because I haven't been giving them enough attention, or if we don't really have a good solution yet. [1] https://bugzilla.kernel.org/show_bug.cgi?id=42679 Sorry, no. This has completely dropped off my radar. I'll try to resurrect it and figure out how to move forward. Thanks, Not a problem; I'm just way behind on processing patches, so I'm trying to clean up my backlog and take care of things that are waiting on me. Bjorn ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] PCI: Introduce new device binding path using pci_dev.driver_override
The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub /sys/bus/pci/devices/:03:00.0/driver_override echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo /sys/bus/pci/devices/:03:00.0/preferred_driver echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (preferred driver = none) or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson alex.william...@redhat.com --- Changes since RFC: - Add ABI documentation (gregkh) - Documentation wording clarification (Christoffer) Nobody puked on the RFC and platform folks have posted a working version of this for platform devices, so I guess the only thing left to do is formally propose this as a new driver binding mechanism. I don't see much incentive to push this into the driver core since the match ultimately needs to be done by the bus driver. I think this is therefore like new_id/remove_id where PCI and USB implement separate, but consistent interfaces. I've pruned the CC list a bit from the RFC, but I've added libvirt folks since I expect they would be the first userspace tool that would adopt this. Thanks, Alex Documentation/ABI/testing/sysfs-bus-pci | 21 drivers/pci/pci-driver.c| 25 +-- drivers/pci/pci-sysfs.c | 40 +++ include/linux/pci.h |1 + 4 files changed, 84 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson alex.william...@redhat.com +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub driver_override) and + may be cleared with an empty string (echo driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + none. Only a single driver may be specified in the override, + there is no support for parsing delimiters. diff --git
