Quoting Lu Baolu (2020-11-20 10:17:12)
> Lu Baolu (3):
> iommu: Add quirk for Intel graphic devices in map_sg
> iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
> iommu/vt-d: Cleanup after converting to dma-iommu ops
>
> Tom Murphy (4):
> iommu: Handle freelists when using de
Quoting Lu Baolu (2020-08-24 07:31:23)
> Hi Chris,
>
> On 2020/8/22 2:33, Chris Wilson wrote:
> > Quoting Lu Baolu (2019-05-25 06:41:28)
> >> This allows the iommu generic layer to allocate a dma domain and
> >> attach it to a device through the iommu api's
Quoting Chris Wilson (2020-08-22 17:02:09)
> Beware that the address size for x86-32 may exceed unsigned long.
>
> [0.368971] UBSAN: shift-out-of-bounds in
> drivers/iommu/intel/iommu.c:128:14
> [0.369055] shift exponent 36 is too large for 32-bit type 'long unsigne
/vt-d: Delegate the dma domain to upper layer")
Signed-off-by: Chris Wilson
Cc: James Sewart
Cc: Lu Baolu
Cc: Joerg Roedel
Cc: # v5.3+
---
drivers/iommu/intel/iommu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c
Quoting Lu Baolu (2019-05-25 06:41:28)
> This allows the iommu generic layer to allocate a dma domain and
> attach it to a device through the iommu api's. With all types of
> domains being delegated to upper layer, we can remove an internal
> flag which was used to distinguish domains mananged inte
q_exit+0xba/0xc0
[2.121471] ---[ end trace 610717c918cf08f3 ]---
[2.121974] DMAR: ACPI name space devices didn't probe correctly
[2.122069] DMAR: Intel(R) Virtualization Technology for Directed I/O
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111906
Signed-off-by: Chris
enabled. Quirk away Broadwell and remove the rotten apple.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89360
Signed-off-by: Chris Wilson
Cc: Lu Baolu
Cc: Martin Peres
Cc: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 44 +
1 file changed, 35
Quoting Robin Murphy (2019-07-22 11:13:49)
> Hi Chris,
>
> On 20/07/2019 19:08, Chris Wilson wrote:
> > Since the cached32_node is allowed to be advanced above dma_32bit_pfn
> > (to provide a shortcut into the limited range), we need to be careful to
> > remove the to
d rbtree node caching")
Signed-off-by: Chris Wilson
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: Joerg Roedel
Cc: # v4.15+
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index d499b2621239..24b9f9b19086
Quoting Lu Baolu (2019-06-22 09:46:36)
> Hi,
>
> On 6/22/19 4:09 PM, Chris Wilson wrote:
> > Quoting Lu Baolu (2019-06-22 07:49:22)
> >> Hi Chris,
> >>
> >> Thanks for the test and report.
> >>
> >> On 6/21/19 9:27 PM, Chris Wilson wro
Quoting Lu Baolu (2019-06-22 07:49:22)
> Hi Chris,
>
> Thanks for the test and report.
>
> On 6/21/19 9:27 PM, Chris Wilson wrote:
> > We see a use-after-free in our CI about 20% of the time on a Skylake
> > iommu testing host, present since enabling that host. Sadl
We see a use-after-free in our CI about 20% of the time on a Skylake
iommu testing host, present since enabling that host. Sadly, it has not
presented itself while running under KASAN.
<4> [302.391799] general protection fault: [#1] PREEMPT SMP PTI
<4> [302.391803] CPU: 7 PID: 4854 Comm: i915
me so far that we should always take
> device_domain_lock first then the iommu lock.
>
> We can continue to try to find the real culprit mentioned in
> 7560cc3ca7d9, but for now I think we should revert it to fix current
> breakage.
>
> CC: Joerg Roedel
> CC: Lu Baolu
> CC: dave.ji...@intel.com
> Signed-off-by: Peter Xu
I've run this through our CI which was also reporting the inversion, so
Tested-by: Chris Wilson
-Chris
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Quoting Lu Baolu (2019-05-21 08:30:15)
> From: Dave Jiang
>
> Lockdep debug reported lock inversion related with the iommu code
> caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
> the device_domain_lock out of order versus the code path in
> iommu_flush_dev_iotlb(). Expanding th
Quoting Daniel Vetter (2019-04-01 14:06:48)
> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring wrote:
> > +{
> > + int i, ret = 0;
> > + struct drm_gem_object *obj;
> > +
> > + spin_lock(&filp->table_lock);
> > +
> > + for (i = 0; i < count; i++) {
> > + /* Check if
Quoting Lu Baolu (2018-05-04 06:08:18)
> The pasid28 quirk is needed only for some pre-production devices.
> Remove it to make the code concise.
Every skylake mixing iommu and i915 is now inoperable on boot. Reads
by the GPU from iommu map pages return zero, writes disappear into the
void, no erro
This extends the warning suppression from commit d0bc0c2a31c9 ("swiotlb:
suppress warning when __GFP_NOWARN is set") to suppress the warnings
when DMA_ATTR_NO_WARN is given by caller. In such cases the caller wants
to handle the error themselves.
Fixes: d0bc0c2a31c9 ("swiotlb: suppress warning whe
Quoting Christian König (2017-08-16 08:49:07)
> Am 16.08.2017 um 04:12 schrieb Chris Mi:
> > Using current TC code, it is very slow to insert a lot of rules.
> >
> > In order to improve the rules update rate in TC,
> > we introduced the following two changes:
> > 1) changed cls_flower to u
{
> + mutex_lock(&pasid_mutex);
> + kref_put(&svm->kref, &intel_mm_free);
> + mutex_unlock(&pasid_mutex);
kref_put_mutex(&svm->kref, intel_mm_free, &pasid_mutex); ?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
19 matches
Mail list logo
