- 16 6月, 2015 16 次提交
-
-
由 Joerg Roedel 提交于
This way we can give the hardware the new IR table right after it has been allocated and initialized. 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 提交于
Move it to this function for now, so that the copy routines for irq remapping take no effect yet. 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 enabled when we program the irq remapping table to hardware in the prepare phase later. 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 need this to be detected already when we program the irq remapping table pointer to hardware. 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 提交于
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>
-
- 02 6月, 2015 1 次提交
-
-
由 Joerg Roedel 提交于
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: NJoerg Roedel <jroedel@suse.de>
-
- 12 5月, 2015 1 次提交
-
-
由 Will Deacon 提交于
Stage 1 translation is controlled by two sets of page tables (TTBR0 and TTBR1) which grow up and down from zero respectively in the ARMv8 translation regime. For the SMMU, we only care about TTBR0 and, in the case of a 48-bit virtual space, we expect to map virtual addresses 0x0 through to 0xffff_ffff_ffff. Given that some masters may be incapable of emitting virtual addresses targetting TTBR1 (e.g. because they sit on a 48-bit bus), the SMMU architecture allows bit 47 to be sign-extended, halving the virtual range of TTBR0 but allowing TTBR1 to be used. This is controlled by the SEP field in TTBCR2. The SMMU driver incorrectly enables this sign-extension feature, which causes problems when userspace addresses are programmed into a master device with the SMMU expecting to map the incoming transactions via TTBR0; if the top bit of address is set, we will instead get a translation fault since TTBR1 walks are disabled in the TTBCR. This patch fixes the issue by disabling sign-extension of a fixed virtual address bit and instead basing the behaviour on the upstream bus size: the incoming address is zero extended unless the upstream bus is only 49 bits wide, in which case bit 48 is used as the sign bit and is replicated to the upper bits. Cc: <stable@vger.kernel.org> # v4.0+ Reported-by: NVarun Sethi <varun.sethi@freescale.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 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)
-
- 05 5月, 2015 1 次提交
-
-
由 Arnd Bergmann 提交于
The rockchip iommu driver references its of_device_id table from the init function, which fails to build when the table is undefined: iommu/rockchip-iommu.c: In function 'rk_iommu_init': iommu/rockchip-iommu.c:1029:35: error: 'rk_iommu_dt_ids' undeclared (first use in this function) np = of_find_matching_node(NULL, rk_iommu_dt_ids); This removes the #ifdef and the corresponding of_match_ptr wrapper to make it build both with CONFIG_OF enabled or disabled. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Fixes: 425061b0 ("iommu/rockchip: Play nice in multi-platform builds") Reviewed-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 04 5月, 2015 1 次提交
-
-
由 Oded Gabbay 提交于
This patch fixes a bug in put_pasid_state_wait that appeared in kernel 4.0 The bug is that pasid_state->count wasn't decremented before entering the wait_event. Thus, the condition in wait_event will never be true. The fix is to decrement (atomically) the pasid_state->count before the wait_event. Signed-off-by: NOded Gabbay <oded.gabbay@amd.com> Cc: stable@vger.kernel.org #v4.0 Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 02 4月, 2015 9 次提交
-
-
由 Joerg Roedel 提交于
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: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Now that fetch_pte returns the page-size of the pte, this function can be optimized too. Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
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: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Now that fetch_pte returns the page-size of the pte, this function can be optimized a lot. Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Extend the fetch_pte function to also return the page-size that is mapped by the returned pte. Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Add code to allocate memory from the contiguous memory allocator to support coherent allocations larger than 8MB. Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Don't explicitly add __GFP_ZERO to the allocator flags. Leave this up to the caller. Tested-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
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: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
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: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 31 3月, 2015 9 次提交
-
-
由 Thierry Reding 提交于
The SMMU on Tegra30 and Tegra114 supports addressing up to 4 GiB of physical memory. On Tegra124 the addressable physical memory was extended to 16 GiB. The page frame number stored in PTEs therefore requires 20 or 22 bits, depending on SoC generation. In order to cope with this, compute the proper value at runtime. Reported-by: NJoseph Lo <josephl@nvidia.com> Cc: Hiroshi Doyu <hdoyu@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Thierry Reding 提交于
The aperture of the domain should always be available, otherwise drivers need to attach first before they can use the aperture geometry. Cc: Hiroshi Doyu <hdoyu@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Thierry Reding 提交于
Each address space in the Tegra SMMU provides 4 GiB worth of addresses. Cc: Hiroshi Doyu <hdoyu@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
All drivers have been converted to the new domain_alloc and domain_free iommu-ops. So remove the old ones and get rid of iommu_domain->priv too, as this is no longer needed when the struct iommu_domain is embedded in the private structures of the iommu drivers. Tested-by: NThierry Reding <treding@nvidia.com> Tested-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Tested-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-