- 12 8月, 2015 1 次提交
-
-
由 Joerg Roedel 提交于
Instead of searching in the domain array for already allocated domain ids, keep track of them explicitly. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 03 8月, 2015 2 次提交
-
-
由 Alex Williamson 提交于
Debugging domain ID leakage typically requires long running tests in order to exhaust the domain ID space or kernel instrumentation to track the setting and clearing of bits. A couple trivial intel-iommu specific sysfs extensions make it much easier to expose the IOMMU capabilities and current usage. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Kees Cook 提交于
This makes sure it won't be possible to accidentally leak format strings into iommu device names. Current name allocations are safe, but this makes the "%s" explicit. Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 23 7月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
This continues the attempt to fix commit fb170fb4 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability"). The previous attempt in commit 71684406 ("iommu/vt-d: Detach domain *only* from attached iommus") overlooked the fact that dmar_domain.iommu_bmp gets cleared for VM domains when devices are detached: intel_iommu_detach_device domain_remove_one_dev_info domain_detach_iommu The domain is detached from the iommu, but the iommu is still attached to the domain, for whatever reason. Thus when we get to domain_exit(), we can't rely on iommu_bmp for VM domains to find the active iommus, we must check them all. Without that, the corresponding bit in intel_iommu.domain_ids doesn't get cleared and repeated VM domain creation and destruction will run out of domain IDs. Meanwhile we still can't call iommu_detach_domain() on arbitrary non-VM domains or we risk clearing in-use domain IDs, as 71684406 attempted to address. It's tempting to modify iommu_detach_domain() to test the domain iommu_bmp, but the call ordering from domain_remove_one_dev_info() prevents it being able to work as fb170fb4 seems to have intended. Caching of unused VM domains on the iommu object seems to be the root of the problem, but this code is far too fragile for that kind of rework to be proposed for stable, so we simply revert this chunk to its state prior to fb170fb4. Fixes: fb170fb4 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability") Fixes: 71684406 ("iommu/vt-d: Detach domain *only* from attached iommus") Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 16 6月, 2015 12 次提交
-
-
由 Joerg Roedel 提交于
Do not touch the TE bit unless we know translation is disabled. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
For all the copy-translation code to run, we have to keep translation enabled in intel_iommu_init(). So remove the code disabling it. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
We can't change the RTT bit when translation is enabled, so don't copy translation tables when we would change the bit with our new root entry. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
When we copied over context tables from an old kernel, we need to defer assignment of devices to domains until the device driver takes over. So skip this part of initialization when we copied over translation tables from the old kernel. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
This seperates the allocation of the si_domain from its assignment to devices. It makes sure that the iommu=pt case still works in the kdump kernel, when we have to defer the assignment of devices to domains to device driver initialization time. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Mark the context entries we copied over from the old kernel, so that we don't detect them as present in other code paths. This makes sure we safely overwrite old context entries when a new domain is assigned. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Mark all domain-ids we find as reserved, so that there could be no collision between domains from the previous kernel and our domains in the IOMMU TLB. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
If we are in a kdump kernel and find translation enabled in the iommu, try to copy the translation tables from the old kernel to preserve the mappings until the device driver takes over. This supports old and the extended root-entry and context-table formats. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Add code to detect whether translation is already enabled in the IOMMU. Save this state in a flags field added to struct intel_iommu. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
In case there was an old root entry, make our new one visible immediately after it was allocated. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
QI needs to be available when we write the root entry into hardware because flushes might be necessary after this. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Give them a common prefix that can be grepped for and improve the wording here and there. Tested-by: NZhenHua Li <zhen-hual@hp.com> Tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 12 6月, 2015 1 次提交
-
-
由 David Woodhouse 提交于
Although the extended tables are theoretically a completely orthogonal feature to PASID and anything else that *uses* the newly-available bits, some of the early hardware has problems even when all we do is enable them and use only the same bits that were in the old context tables. For now, there's no motivation to support extended tables unless we're going to use PASID support to do SVM. So just don't use them unless PASID support is advertised too. Also add a command-line bailout just in case later chips also have issues. The equivalent problem for PASID support has already been fixed with the upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register"), because the problematic platforms use the old definition of the PASID-capable bit, which is now marked as reserved and meaningless. So with this change, we'll magically start using ECS again only when we see the new hardware advertising "hey, we have PASID support and we actually tested it this time" on bit 40. The VT-d hardware architect has promised that we are not going to have any reason to support ECS *without* PASID any time soon, and he'll make sure he checks with us before changing that. In the future, if hypothetical new features also use new bits in the context tables and can be seen on implementations *without* PASID support, we might need to add their feature bits to the ecs_enabled() macro. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 11 5月, 2015 1 次提交
-
-
由 David Woodhouse 提交于
When we use 'intel_iommu=igfx_off' to disable translation for the graphics, and when we discover that the BIOS has misconfigured the DMAR setup for I/OAT, we use a special DUMMY_DEVICE_DOMAIN_INFO value in dev->archdata.iommu to indicate that translation is disabled. With passthrough mode, we were attempting to dereference that as a normal pointer to a struct device_domain_info when setting up an identity mapping for the affected device. This fixes the problem by making device_to_iommu() explicitly check for the special value and indicate that no IOMMU was found to handle the devices in question. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org (which means you can pick up 18436afd now too)
-
- 31 3月, 2015 1 次提交
-
-
由 Joerg Roedel 提交于
Get rid of domain_init and domain_destroy and implement domain_alloc/domain_free instead. Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 25 3月, 2015 2 次提交
-
-
由 David Woodhouse 提交于
Add a new function iommu_context_addr() which takes care of the differences and returns a pointer to a context entry which may be in either format. The formats are binary compatible for all the old fields anyway; the new one is just larger and some of the reserved bits in the original 128 are now meaningful. So far, nothing actually uses the new fields in the extended context entry. Modulo hardware bugs with interpreting the new-style tables, this should basically be a no-op. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. There's already an exclusion for USB devices, because we know the only reason for RMRRs there is a misguided desire to keep legacy keyboard/mouse emulation running in some theoretical OS which doesn't have support for USB in its own right... but which *does* enable the IOMMU. Add an exclusion for graphics devices too, so that 'iommu=pt' works there. We should be able to successfully assign graphics devices to guests too, as long as the initial handling of stolen memory is reconfigured appropriately. This has certainly worked in the past. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org
-
- 24 3月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
Unused after commit 71684406 ("iommu/vt-d: Detach domain *only* from attached iommus"). Reported by 0-day builder. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 23 3月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
Device domains never span IOMMU hardware units, which allows the domain ID space for each IOMMU to be an independent address space. Therefore we can have multiple, independent domains, each with the same domain->id, but attached to different hardware units. This is also why we need to do a heavy-weight search for VM domains since they can span multiple IOMMUs hardware units and we don't require a single global ID to use for all hardware units. Therefore, if we call iommu_detach_domain() across all active IOMMU hardware units for a non-VM domain, the result is that we clear domain IDs that are not associated with our domain, allowing them to be re-allocated and causing apparent coherency issues when the device cannot access IOVAs for the intended domain. This bug was introduced in commit fb170fb4 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability"), but is significantly exacerbated by the more recent commit 62c22167 ("iommu/vt-d: Fix dmar_domain leak in iommu_attach_device") which calls domain_exit() more frequently to resolve a domain leak. Fixes: fb170fb4 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability") Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 17 3月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Now that the ACPI companions of devices are represented by pointers to struct fwnode_handle, it is not quite efficient to check whether or not an ACPI companion of a device is present by evaluating the ACPI_COMPANION() macro. For this reason, introduce a special static inline routine for that, has_acpi_companion(), and update the code to use it where applicable. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 3月, 2015 1 次提交
-
-
由 Quentin Lambert 提交于
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: NQuentin Lambert <lambert.quentin@gmail.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 19 1月, 2015 3 次提交
-
-
由 Robin Murphy 提交于
Systems may contain heterogeneous IOMMUs supporting differing minimum page sizes, which may also not be common with the CPU page size. Thus it is practical to have an explicit notion of IOVA granularity to simplify handling of mapping and allocation constraints. As an initial step, move the IOVA page granularity from an implicit compile-time constant to a per-domain property so we can make use of it in IOVA domain context at runtime. To keep the abstraction tidy, extend the little API of inline iova_* helpers to parallel some of the equivalent PAGE_* macros. Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Robin Murphy 提交于
To share the IOVA allocator with other architectures, it needs to accommodate more general aperture restrictions; move the lower limit from a compile-time constant to a runtime domain property to allow IOVA domains with different requirements to co-exist. Also reword the slightly unclear description of alloc_iova since we're touching it anyway. Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Robin Murphy 提交于
In order to share the IOVA allocator with other architectures, break the unnecssary dependency on the Intel IOMMU driver and move the remaining IOVA internals to iova.c Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 05 1月, 2015 2 次提交
-
-
由 Joerg Roedel 提交于
This code only runs when action == BUS_NOTIFY_REMOVED_DEVICE, so it can't be BUS_NOTIFY_DEL_DEVICE. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Since commit 1196c2fb a domain is only destroyed in the notifier path if it is hot-unplugged. This caused a domain leakage in iommu_attach_device when a driver was unbound from the device and bound to VFIO. In this case the device is attached to a new domain and unlinked from the old domain. At this point nothing points to the old domain anymore and its memory is leaked. Fix this by explicitly freeing the old domain in iommu_attach_domain. Fixes: 1196c2fb (iommu/vt-d: Fix dmar_domain leak in iommu_attach_device) Cc: stable@vger.kernel.org # v3.18 Tested-by: NJerry Hoemann <jerry.hoemann@hp.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 02 12月, 2014 1 次提交
-
-
由 Jiang Liu 提交于
There's an off-by-one bug in function __domain_mapping(), which may trigger the BUG_ON(nr_pages < lvl_pages) when (nr_pages + 1) & superpage_mask == 0 The issue was introduced by commit 9051aa02 "intel-iommu: Combine domain_pfn_mapping() and domain_sg_mapping()", which sets sg_res to "nr_pages + 1" to avoid some of the 'sg_res==0' code paths. It's safe to remove extra "+1" because sg_res is only used to calculate page size now. Reported-And-Tested-by: NSudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: <stable@vger.kernel.org> # >= 3.0 Acked-By: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 18 11月, 2014 4 次提交
-
-
由 Jiang Liu 提交于
Implement required callback functions for intel-iommu driver to support DMAR unit hotplug. Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Reviewed-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Jiang Liu 提交于
On Intel platforms, an IO Hub (PCI/PCIe host bridge) may contain DMAR units, so we need to support DMAR hotplug when supporting PCI host bridge hotplug on Intel platforms. According to Section 8.8 "Remapping Hardware Unit Hot Plug" in "Intel Virtualization Technology for Directed IO Architecture Specification Rev 2.2", ACPI BIOS should implement ACPI _DSM method under the ACPI object for the PCI host bridge to support DMAR hotplug. This patch introduces interfaces to parse ACPI _DSM method for DMAR unit hotplug. It also implements state machines for DMAR unit hot-addition and hot-removal. The PCI host bridge hotplug driver should call dmar_hotplug_hotplug() before scanning PCI devices connected for hot-addition and after destroying all PCI devices for hot-removal. Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Reviewed-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Jiang Liu 提交于
Introduce functions to support dynamic IOMMU seq_id allocating and releasing, which will be used to support DMAR hotplug. Also rename IOMMU_UNITS_SUPPORTED as DMAR_UNITS_SUPPORTED. Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Reviewed-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Jiang Liu 提交于
Introduce helper function dmar_walk_resources to walk resource entries in DMAR table and ACPI buffer object returned by ACPI _DSM method for IOMMU hot-plug. Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 06 11月, 2014 1 次提交
-
-
由 Li, Zhen-Hua 提交于
The function context_set_address_root() and set_root_value are setting new address in a wrong way, and this patch is trying to fix this problem. According to Intel Vt-d specs(Feb 2011, Revision 1.3), Chapter 9.1 and 9.2, field ctp in root entry is using bits 12:63, field asr in context entry is using bits 12:63. To set these fields, the following functions are used: static inline void context_set_address_root(struct context_entry *context, unsigned long value); and static inline void set_root_value(struct root_entry *root, unsigned long value) But they are using an invalid method to set these fields, in current code, only a '|' operator is used to set it. This will not set the asr to the expected value if it has an old value. For example: Before calling this function, context->lo = 0x3456789012111; value = 0x123456789abcef12; After we call context_set_address_root(context, value), expected result is context->lo == 0x123456789abce111; But the actual result is: context->lo == 0x1237577f9bbde111; So we need to clear bits 12:63 before setting the new value, this will fix this problem. Signed-off-by: NLi, Zhen-Hua <zhen-hual@hp.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 04 11月, 2014 1 次提交
-
-
由 Olav Haugan 提交于
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: NOlav Haugan <ohaugan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 02 10月, 2014 1 次提交
-
-
由 Joerg Roedel 提交于
This makes sure any RMRR mappings stay in place when the driver is unbound from the device. Signed-off-by: NJoerg Roedel <jroedel@suse.de> Tested-by: NJerry Hoemann <jerry.hoemann@hp.com>
-
- 25 9月, 2014 1 次提交
-
-
由 Joerg Roedel 提交于
Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 18 8月, 2014 1 次提交
-
-
由 Joerg Roedel 提交于
When the BUS_NOTIFY_DEL_DEVICE event is received the device might still be attached to a driver. In this case the domain can't be released as the mappings might still be in use. Defer the domain removal in this case until we receivce the BUS_NOTIFY_UNBOUND_DRIVER event. Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: stable@vger.kernel.org # v3.15, v3.16 Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-