Re: [PATCH v2] iommu/vt-d: Don't be too aggressive when clearing one context entry

On Thu, 2017-08-31 at 10:58 +0200, Filippo Sironi wrote: > Previously, we were invalidating context cache and IOTLB globally when > clearing one context entry.  This is a tad too aggressive. > Invalidate the context cache and IOTLB for the interested device only. > > Signed-off-by: Filippo Sironi

Re: [PATCH 2/4] iommu: add a bitmap based dma address allocator

On Wed, 2015-11-25 at 15:46 +0100, jroe...@suse.de wrote: > On Tue, Nov 24, 2015 at 02:05:12PM -0800, Shaohua Li wrote: > > The lib/iommu-common.c uses a bitmap and a lock. This implementation > > actually uses a percpu_ida which completely avoids locking. It would be > > possible to make

Re: [patch] iommu/vt-d: shift wrapping bug in prq_event_thread()

On Thu, 2015-10-15 at 21:25 +0300, Dan Carpenter wrote: > The "req->addr" variable is a bit field declared as "u64 addr:52;". > The "address" variable is a u64. We need to cast "req->addr" to a u64 > before the shift or the result is truncated to 52 bits. > > Fixes: 0b9252a34858 ('iommu/vt-d:

Re: iommu/vt-d: Implement page request handling

On Thu, 2015-10-15 at 21:25 +0300, Dan Carpenter wrote: > > The patch 0b9252a34858: "iommu/vt-d: Implement page request handling" > from Oct 8, 2015, leads to the following Smatch complaint: > > drivers/iommu/intel-svm.c:452 prq_event_thread() > error: we previously assumed 'svm' could

Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT

On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote: > From: Sudeep Dutt > > iova is a library which can be built without IOMMU_SUPPORT > > Signed-off-by: Sudeep Dutt The first three of these patches are in 4.3-rc4 already. Apologies for the

Re: Intel-iommu panic on kernel v4.1-rc1

On Mon, 2015-04-27 at 15:27 +0800, sl4e...@gmail.com wrote: commit 18436afdc11a00ac881990b454cfb2eae81d6003 iommu/vt-d: Allow RMRR on graphics devices too cause kernel panic with Z77+vt-d and kernel parameters: intel_iommu=igfx_off iommu=pt the panic path is:

Re: hpsa driver bug crack kernel down!

On Wed, 2014-04-16 at 15:37 +0200, j...@8bytes.org wrote: Hey David, On Mon, Apr 14, 2014 at 05:03:51PM +, Woodhouse, David wrote: Jiang, if you can then let me have a copy with a signed-off-by I'll shepherd it upstream along with your other patch which is already in my iommu-2.6.git

Re: hpsa driver bug crack kernel down!

On Mon, 2014-04-14 at 09:47 -0700, Davidlohr Bueso wrote: On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to

Re: [PATCH 21/33] iommu/vt-d: Make get_domain_for_dev() take struct device

On Mon, 2014-04-14 at 15:22 -0600, Alex Williamson wrote: + if (dev_tmp) { + if (pci_is_pcie(dev_tmp)) { + bridge_bus = dev_tmp-subordinate-number; + bridge_devfn = 0; + } else {

Re: hpsa driver bug crack kernel down!

On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: Attaching a dmesg from one of the kernels that boots. It doesn't appear to have much of the related information... is there any debug config option I can enable that might give you more data? I'd like the contents of

Re: hpsa driver bug crack kernel down!

On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote: [+ David, VT-d maintainer ] Jiang, David, can you please have a look into this issue? DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read]

Re: hpsa driver bug crack kernel down!

On Thu, 2014-04-10 at 09:14 -0600, Bjorn Helgaas wrote: Thus, my first guess would be that we are quite happily setting up the requested DMA maps on the *wrong* IOMMU, and then taking faults when the device actually tries to do DMA. I like the wrong IOMMU (or no IOMMU at all) theory. If

Re: hpsa driver bug crack kernel down!

On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 That Present bit in context entry is clear fault means that we have not set up *any* mappings for this PCI device… on this IOMMU. Yes,

Re: [PATCH] iommu/vt-d: Check for NULL pointer in dmar_acpi_dev_scope_init() array

On Tue, 2014-03-25 at 20:30 +0100, Joerg Roedel wrote: When ir_dev_scope_init() is called via a rootfs initcall it will check for irq_remapping_enabled before it calls (indirectly) into dmar_acpi_dev_scope_init() which uses the dmar_tbl pointer without any checks. Ew. If

[PATCH 34/33] iommu/vt-d: Fix RCU annotations on device scope lists

In commit d78e0ac577 (iommu/vt-d: Change scope lists to struct device, bus, devfn) I converted the 'struct device *' arrays into an array of 'struct dmar_dev_scope', where: struct dmar_dev_scope { struct device *dev; u8 bus; u8 devfn; }; That commit contained changes such as

[PATCH] intel-iommu: Free old page tables before creating superpage

The dma_pte_free_pagetable() function will only free a page table page if it is asked to free the *entire* 2MiB range that it covers. So if a page table page was used for one or more small mappings, it's likely to end up still present in the page tables... but with no valid PTEs. This was fine

[PATCH] intel-iommu: Free old page tables before creating superpage

The dma_pte_free_pagetable() function will only free a page table page if it is asked to free the *entire* 2MiB range that it covers. So if a page table page was used for one or more small mappings, it's likely to end up still present in the page tables... but with no valid PTEs. This was fine