- 26 6月, 2009 1 次提交
-
-
由 Chris Wright 提交于
Drop the e820 scanning and use existing function for finding valid RAM regions to add to 1:1 mapping. Signed-off-by: NChris Wright <chrisw@redhat.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 24 6月, 2009 1 次提交
-
-
由 Fenghua Yu 提交于
Identity mapping for IOMMU defines a single domain to 1:1 map all PCI devices to all usable memory. This reduces map/unmap overhead in DMA API's and improve IOMMU performance. On 10Gb network cards, Netperf shows no performance degradation compared to non-IOMMU performance. This method may lose some of DMA remapping benefits like isolation. The patch sets up identity mapping for all PCI devices to all usable memory. In the DMA API, there is no overhead to maintain page tables, invalidate iotlb, flush cache etc. 32 bit DMA devices don't use identity mapping domain, in order to access memory beyond 4GiB. When kernel option iommu=pt, pass through is first tried. If pass through succeeds, IOMMU goes to pass through. If pass through is not supported in hw or fail for whatever reason, IOMMU goes to identity mapping. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 18 5月, 2009 2 次提交
-
-
由 Yu Zhao 提交于
Enable the device IOTLB (i.e. ATS) for both the bare metal and KVM environments. Signed-off-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Yu Zhao 提交于
Make iommu_flush_iotlb_psi() and flush_unmaps() more readable. Signed-off-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 11 5月, 2009 5 次提交
-
-
由 David Woodhouse 提交于
PAGE_MASK is 0xFFFFF000 on i386 -- even with PAE. So it's not sufficient to ensure that you use phys_addr_t or uint64_t everywhere you handle physical addresses -- you also have to avoid using the construct 'addr & PAGE_MASK', because that will strip the high 32 bits of the address. This patch avoids that problem by using PHYSICAL_PAGE_MASK instead of PAGE_MASK where appropriate. It leaves '& PAGE_MASK' in a few instances that don't matter -- where it's being used on the virtual bus addresses we're dishing out, which are 32-bit anyway. Since PHYSICAL_PAGE_MASK is not present on other architectures, we have to define it (to PAGE_MASK) if it's not already defined. Maybe it would be better just to fix PAGE_MASK for i386/PAE? Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
In iommu_flush_write_buffer() we read iommu->gcmd before taking the register_lock, and then we mask in the WBF bit and write it to the register. There is a tiny chance that something else could have _changed_ iommu->gcmd before we take the lock, but after we read it. So we could be undoing that change. Never actually going to have happened in practice, since nothing else changes that register at runtime -- aside from the write-buffer flush it's only ever touched at startup for enabling translation, etc. But worth fixing anyway. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
As we just did for context cache flushing, clean up the logic around whether we need to flush the iotlb or just the write-buffer, depending on caching mode. Fix the same bug in qi_flush_iotlb() that qi_flush_context() had -- it isn't supposed to be returning an error; it's supposed to be returning a flag which triggers a write-buffer flush. Remove some superfluous conditional write-buffer flushes which could never have happened because they weren't for non-present-to-present mapping changes anyway. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
It really doesn't make a lot of sense to have some of the logic to handle caching vs. non-caching mode duplicated in qi_flush_context() and __iommu_flush_context(), while the return value indicates whether the caller should take other action which depends on the same thing. Especially since qi_flush_context() thought it was returning something entirely different anyway. This patch makes qi_flush_context() and __iommu_flush_context() both return void, removes the 'non_present_entry_flush' argument and makes the only call site which _set_ that argument to 1 do the right thing. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 10 5月, 2009 1 次提交
-
-
由 Yu Zhao 提交于
The domain->id is a sequence number associated with the KVM guest and should not be used for the context flush. This patch replaces the domain->id with a proper id value for both bare metal and KVM. Signed-off-by: NYu Zhao <yu.zhao@intel.com> Acked-by: NWeidong Han <weidong.han@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 01 5月, 2009 1 次提交
-
-
由 Fenghua Yu 提交于
This updated patch should fix the compiling errors and remove the extern iommu_pass_through from drivers/pci/intel-iommu.c file. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 29 4月, 2009 1 次提交
-
-
由 Fenghua Yu 提交于
The patch adds kernel parameter intel_iommu=pt to set up pass through mode in context mapping entry. This disables DMAR in linux kernel; but KVM still runs on VT-d and interrupt remapping still works. In this mode, kernel uses swiotlb for DMA API functions but other VT-d functionalities are enabled for KVM. KVM always uses multi level translation page table in VT-d. By default, pass though mode is disabled in kernel. This is useful when people don't want to enable VT-d DMAR in kernel but still want to use KVM and interrupt remapping for reasons like DMAR performance concern or debug purpose. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Acked-by: NWeidong Han <weidong@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 19 4月, 2009 1 次提交
-
-
由 Weidong Han 提交于
Currently, when x2apic is not enabled, interrupt remapping will be enabled in init_dmars(), where it is too late to remap ioapic interrupts, that is, ioapic interrupts are really in compatibility mode, not remappable mode. This patch always enables interrupt remapping before ioapic setup, it guarantees all interrupts will be remapped when interrupt remapping is enabled. Thus it doesn't need to set the compatibility interrupt bit. [ Impact: refactor intr-remap init sequence, enable fuller remap mode ] Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NWeidong Han <weidong.han@intel.com> Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com> Cc: iommu@lists.linux-foundation.org Cc: allen.m.kay@intel.com Cc: fenghua.yu@intel.com LKML-Reference: <1239957736-6161-4-git-send-email-weidong.han@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 07 4月, 2009 4 次提交
-
-
由 Yang Hongyang 提交于
Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Yang Hongyang 提交于
Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Fenghua Yu 提交于
This issue was pointed out by Linus. In dma_pte_clear_range() in intel-iommu.c start = PAGE_ALIGN(start); end &= PAGE_MASK; npages = (end - start) / VTD_PAGE_SIZE; In partial page case, start could be bigger than end and npages will be negative. Currently the issue doesn't show up as a real bug in because start and end have been aligned to page boundary already by all callers. So the issue has been hidden. But it is dangerous programming practice. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
It's possible for a device in the drhd->devices[] array to be NULL if it wasn't found at boot time, which means we have to check for that case. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 04 4月, 2009 4 次提交
-
-
由 David Woodhouse 提交于
We were comparing {bus,devfn} and assuming that a match meant it was the same device. It doesn't -- the same {bus,devfn} can exist in multiple PCI domains. Include domain number in device identification (and call it 'segment' in most places, because there's already a lot of references to 'domain' which means something else, and this code is infected with ACPI thinking already). Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
When the DMAR table identifies that a PCI-PCI bridge belongs to a given IOMMU, that means that the bridge and all devices behind it should be associated with the IOMMU. Not just the bridge itself. This fixes the device_to_iommu() function accordingly. (It's broken if you have the same PCI bus numbers in multiple domains, but this function was always broken in that way; I'll be dealing with that later). Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Han, Weidong 提交于
interrupt remapping must be enabled before enabling x2apic, but interrupt remapping doesn't depend on x2apic, it can be used separately. Enable interrupt remapping in init_dmars even x2apic is not supported. [dwmw2: Update Kconfig accordingly, fix build with INTR_REMAP && !X2APIC] Signed-off-by: NWeidong Han <weidong.han@intel.com> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Fenghua Yu 提交于
This patch implements the suspend and resume feature for Intel IOMMU DMAR. It hooks to kernel suspend and resume interface. When suspend happens, it saves necessary hardware registers. When resume happens, it restores the registers and restarts IOMMU by enabling translation, setting up root entry, and re-enabling queued invalidation. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 26 3月, 2009 2 次提交
-
-
由 Zhao, Yu 提交于
The problem is in dma_pte_clear_range and dma_pte_free_pagetable. When intel_unmap_single and intel_unmap_sg call them, the end address may be zero if the 'start_addr + size' rounds up. So no PTE gets cleared. The uncleared PTE fires the BUG_ON when it's used again to create new mappings. After I modified dma_pte_clear_range a bit, the BUG_ON is gone. Tested both 32 and 32 PAE modes on Intel X58 and Q35 platforms. Signed-off-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
If we fix a few highmem-related thinkos and a couple of printk format warnings, the Intel IOMMU driver works fine in a 32-bit kernel. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 25 3月, 2009 1 次提交
-
-
由 Han, Weidong 提交于
When assign a device behind conventional PCI bridge or PCIe to PCI/PCI-x bridge to a domain, it must assign its bridge and may also need to assign secondary interface to the same domain. Dependent assignment is already there, but dependent deassignment is missed when detach device from virtual machine. This results in conventional PCI device assignment failure after it has been assigned once. This patch addes dependent deassignment, and fixes the issue. Signed-off-by: NWeidong Han <weidong.han@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 24 3月, 2009 3 次提交
-
-
由 Sheng Yang 提交于
The user can request to enable snooping control through VT-d page table. Signed-off-by: NSheng Yang <sheng@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Sheng Yang 提交于
This iommu_op can tell if domain have a specific capability, like snooping control for Intel IOMMU, which can be used by other components of kernel to adjust the behaviour. Signed-off-by: NSheng Yang <sheng@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Sheng Yang 提交于
Snooping control enabled IOMMU to guarantee DMA cache coherency and thus reduce software effort (VMM) in maintaining effective memory type. Signed-off-by: NSheng Yang <sheng@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 20 3月, 2009 1 次提交
-
-
由 Frank Seidel 提交于
According to kerneljanitors todo list all printk calls (beginning a new line) should have an according KERN_* constant. Those are the missing pieces here for the pci subsystem. Signed-off-by: NFrank Seidel <frank@f-seidel.de> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 3月, 2009 3 次提交
-
-
由 Suresh Siddha 提交于
Impact: cleanup/sanitization Start from a sane state while enabling dma and interrupt-remapping, by clearing the previous recorded faults and disabling previously enabled queued invalidation and interrupt-remapping. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Suresh Siddha 提交于
Impact: interface augmentation (not yet used) Enable fault handling flow for intr-remapping aswell. Fault handling code now shared by both dma-remapping and intr-remapping. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Suresh Siddha 提交于
Impact: code movement Move page fault handling code to dmar.c This will be shared both by DMA-remapping and Intr-remapping code. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 18 2月, 2009 1 次提交
-
-
由 David Woodhouse 提交于
This is the cause of the DMA faults and disk corruption that people have been seeing. Some chipsets neglect to report the RWBF "capability" -- the flag which says that we need to flush the chipset write-buffer when changing the DMA page tables, to ensure that the change is visible to the IOMMU. Override that bit on the affected chipsets, and everything is happy again. Thanks to Chris and Bhavesh and others for helping to debug. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Tested-by: NChris Wright <chrisw@sous-sol.org> Reviewed-by: NBhavesh Davda <bhavesh@vmware.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 2月, 2009 1 次提交
-
-
由 David Woodhouse 提交于
This is the cause of the DMA faults and disk corruption that people have been seeing. Some chipsets neglect to report the RWBF "capability" -- the flag which says that we need to flush the chipset write-buffer when changing the DMA page tables, to ensure that the change is visible to the IOMMU. Override that bit on the affected chipsets, and everything is happy again. Thanks to Chris and Bhavesh and others for helping to debug. Should resolve: https://bugzilla.redhat.com/show_bug.cgi?id=479996 http://bugzilla.kernel.org/show_bug.cgi?id=12578Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Tested-and-acked-by: NChris Wright <chrisw@sous-sol.org> Reviewed-by: NBhavesh Davda <bhavesh@vmware.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 05 2月, 2009 1 次提交
-
-
由 Kyle McMartin 提交于
Due to recurring issues with DMAR support on certain platforms. There's a number of filesystem corruption incidents reported: https://bugzilla.redhat.com/show_bug.cgi?id=479996 http://bugzilla.kernel.org/show_bug.cgi?id=12578 Provide a Kconfig option to change whether it is enabled by default. If disabled, it can still be reenabled by passing intel_iommu=on to the kernel. Keep the .config option off by default. Signed-off-by: NKyle McMartin <kyle@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Acked-By: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 29 1月, 2009 2 次提交
-
-
由 FUJITA Tomonori 提交于
The dma ops unification enables X86 and IA64 to share intel_dma_ops so we can make dma mapping functions static. This also remove unused intel_map_single(). Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 FUJITA Tomonori 提交于
dma_mapping_error is used to see if dma_map_single and dma_map_page succeed. IA64 VT-d dma_mapping_error always says that dma_map_single is successful even though it could fail. Note that X86 VT-d works properly in this regard. This patch fixes IA64 VT-d dma_mapping_error by adding VT-d's own dma_mapping_error() that works for both X86_64 and IA64. VT-d uses zero as an error dma address so VT-d's dma_mapping_error returns 1 if a passed dma address is zero (as x86's VT-d dma_mapping_error does now). Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 14 1月, 2009 1 次提交
-
-
由 Dirk Hohndel 提交于
With some broken BIOSs when VT-d is enabled, the data structures are filled incorrectly. This can cause a NULL pointer dereference in very early boot. Signed-off-by: NDirk Hohndel <hohndel@linux.intel.com> Acked-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 1月, 2009 3 次提交
-
-
由 FUJITA Tomonori 提交于
This converts X86 and IA64 to use include/linux/dma-mapping.h. It's a bit large but pretty boring. The major change for X86 is converting 'int dir' to 'enum dma_data_direction dir' in DMA mapping operations. The major changes for IA64 is using map_page and unmap_page instead of map_single and unmap_single. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 FUJITA Tomonori 提交于
This patch converts dma_map_single and dma_unmap_single to use map_page and unmap_page respectively and removes unnecessary map_single and unmap_single in struct dma_mapping_ops. This leaves intel-iommu's dma_map_single and dma_unmap_single since IA64 uses them. They will be removed after the unification. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 FUJITA Tomonori 提交于
This is a preparation of struct dma_mapping_ops unification. We use map_page and unmap_page instead of map_single and unmap_single. This uses a temporary workaround, ifdef X86_64 to avoid IA64 build. The workaround will be removed after the unification. Well, changing x86's struct dma_mapping_ops could break IA64. It's just wrong. It's one of problems that this patchset fixes. We will remove map_single and unmap_single hooks in the last patch in this patchset. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-