On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The traversing of this list requires protection_domain->lock to be taken
to avoid nasty races with attach/detach code. Make sure the lock is held
on all code-paths traversing this list.
Reported-by: Filippo Sironi
Fixes: 92d420ec028d ("
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
Make sure that attaching a detaching a device can't race against each
other and protect the iommu_dev_data with a spin_lock in these code
paths.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-off-by: Joerg Roedel
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
Check early in attach_device whether the device is already attached to a
domain. This also simplifies the code path so that __attach_device() can
be removed.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-off-by:
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The code-paths before __attach_device() and __detach_device() are called
also access and modify domain state, so take the domain lock there too.
This allows to get rid of the __detach_device() function.
Fixes: 92d420ec028d ("iommu/amd: R
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
The lock is not necessary because the device table does not
contain shared state that needs protection. Locking is only
needed on an individual entry basis, and that needs to
happen on the iommu_dev_data level.
Fixes: 92d420ec028d ("iomm
On Wed Sep 25 19, Joerg Roedel wrote:
From: Joerg Roedel
This struct member was used to track whether a domain
change requires updates to the device-table and IOMMU cache
flushes. The problem is, that access to this field is racy
since locking in the common mapping code-paths has been
eliminate
In case of 4k video buffer, the allocation from a reserved memory is
taking a long time, ~500ms. This is root caused to the memset()
operations on the allocated memory which is consuming more cpu cycles.
Due to this delay, we see that initial frames are being dropped.
To fix this, we have wrapped
Hi Jerry,
On Wed, Sep 25, 2019 at 05:25:15PM -0700, Jerry Snitselaar wrote:
> On Wed Sep 25 19, Joerg Roedel wrote:
> > Joerg Roedel (6):
> > iommu/amd: Remove domain->updated
> > iommu/amd: Remove amd_iommu_devtable_lock
> > iommu/amd: Take domain->lock for complete attach/detach path
> > iom
On Thu, Sep 26, 2019 at 10:35:24AM +0800, Lu Baolu wrote:
[...]
> > > @@ -0,0 +1,342 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/**
> > > + * intel-pgtable.c - Intel IOMMU page table manipulation library
> >
> > Could this be a bit misleading? Normally I'll use "IOMMU page table"
> >
Hi Peter,
Thanks for reviewing my code.
On 9/25/19 1:21 PM, Peter Xu wrote:
On Mon, Sep 23, 2019 at 08:24:52PM +0800, Lu Baolu wrote:
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
intel_mmmap_range(domain, addr, end, phys_a
Hi Kevin,
On 9/25/19 3:32 PM, Tian, Kevin wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Wednesday, September 25, 2019 2:52 PM
Hi Peter and Kevin,
On 9/25/19 1:24 PM, Peter Xu wrote:
On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
From: Peter Xu [mailto:pet...@red
Hi Peter,
On 9/25/19 4:52 PM, Peter Xu wrote:
On Wed, Sep 25, 2019 at 08:02:23AM +, Tian, Kevin wrote:
From: Peter Xu [mailto:pet...@redhat.com]
Sent: Wednesday, September 25, 2019 3:45 PM
On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
From: Peter Xu [mailto:pet...@redhat.co
On Wed Sep 25 19, Joerg Roedel wrote:
Hi,
here are a couple of fixes for the amd iommu driver to fix a
few locking issues around protection-domains. Main problem
was that some traversals of ->dev_list were not locked in
any form, causing potential race conditions.
But there are more issues fixe
Ping. Please take a look at this trivial patch.
On Tue, 2019-09-17 at 09:00 -0400, Qian Cai wrote:
> dma_get_device_base() was first introduced in the commit c41f9ea998f3
> ("drivers: dma-coherent: Account dma_pfn_offset when used with device
> tree"). Later, it was removed by the commit 43fc509c3
Till now the Rockchip iommu driver walked through the irq list via
platform_get_irq() until it encountered an ENXIO error. With the
recent change to add a central error message, this always results
in such an error for each iommu on probe and shutdown.
To not confuse people, switch to platform_cou
> On 25. Sep 2019, at 06:23, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The traversing of this list requires protection_domain->lock to be taken
> to avoid nasty races with attach/detach code. Make sure the lock is held
> on all code-paths traversing this list.
>
> Reported-by: Filippo
> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> Make sure that attaching a detaching a device can't race against each
> other and protect the iommu_dev_data with a spin_lock in these code
> paths.
>
> Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path
> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> Check early in attach_device whether the device is already attached to a
> domain. This also simplifies the code path so that __attach_device() can
> be removed.
>
> Fixes: 92d420ec028d ("iommu/amd: Relax locking in
> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The code-paths before __attach_device() and __detach_device() are called
> also access and modify domain state, so take the domain lock there too.
> This allows to get rid of the __detach_device() function.
>
> Fixe
> On 25. Sep 2019, at 08:50, Sironi, Filippo wrote:
>
>
>
>> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>>
>> From: Joerg Roedel
>>
>> The lock is not necessary because the device table does not
>> contain shared state that needs protection. Locking is only
>> needed on an individual
> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The lock is not necessary because the device table does not
> contain shared state that needs protection. Locking is only
> needed on an individual entry basis, and that needs to
> happen on the iommu_dev_data level.
> On 25. Sep 2019, at 06:22, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> This struct member was used to track whether a domain
> change requires updates to the device-table and IOMMU cache
> flushes. The problem is, that access to this field is racy
> since locking in the common mapping c
From: Joerg Roedel
The lock is not necessary because the device table does not
contain shared state that needs protection. Locking is only
needed on an individual entry basis, and that needs to
happen on the iommu_dev_data level.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
S
From: Joerg Roedel
The code-paths before __attach_device() and __detach_device() are called
also access and modify domain state, so take the domain lock there too.
This allows to get rid of the __detach_device() function.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-of
From: Joerg Roedel
This struct member was used to track whether a domain
change requires updates to the device-table and IOMMU cache
flushes. The problem is, that access to this field is racy
since locking in the common mapping code-paths has been
eliminated.
Move the updated field to the stack
From: Joerg Roedel
Make sure that attaching a detaching a device can't race against each
other and protect the iommu_dev_data with a spin_lock in these code
paths.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c |
From: Joerg Roedel
Check early in attach_device whether the device is already attached to a
domain. This also simplifies the code path so that __attach_device() can
be removed.
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path")
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_io
From: Joerg Roedel
The traversing of this list requires protection_domain->lock to be taken
to avoid nasty races with attach/detach code. Make sure the lock is held
on all code-paths traversing this list.
Reported-by: Filippo Sironi
Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops path
Hi,
here are a couple of fixes for the amd iommu driver to fix a
few locking issues around protection-domains. Main problem
was that some traversals of ->dev_list were not locked in
any form, causing potential race conditions.
But there are more issues fixed here, for example the racy
access to p
On Wed, Sep 25, 2019 at 08:02:23AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, September 25, 2019 3:45 PM
> >
> > On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > > > From: Peter Xu [mailto:pet...@redhat.com]
> > > > Sent: Wednesday,
On Wed, Sep 25, 2019 at 07:32:48AM +, Tian, Kevin wrote:
> > From: Lu Baolu [mailto:baolu...@linux.intel.com]
> > Sent: Wednesday, September 25, 2019 2:52 PM
> >
> > Hi Peter and Kevin,
> >
> > On 9/25/19 1:24 PM, Peter Xu wrote:
> > > On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wro
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 3:45 PM
>
> On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > > From: Peter Xu [mailto:pet...@redhat.com]
> > > Sent: Wednesday, September 25, 2019 2:57 PM
> > >
> > > On Wed, Sep 25, 2019 at 10:48:32A
On Wed, Sep 25, 2019 at 07:21:51AM +, Tian, Kevin wrote:
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, September 25, 2019 2:57 PM
> >
> > On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote:
> > > Hi Kevin,
> > >
> > > On 9/24/19 3:00 PM, Tian, Kevin wrote:
> > > > >
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 2:50 PM
>
> On Mon, Sep 23, 2019 at 08:24:54PM +0800, Lu Baolu wrote:
> > +/*
> > + * Check and return whether first level is used by default for
> > + * DMA translation.
> > + */
> > +static bool first_level_by_defa
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Wednesday, September 25, 2019 2:52 PM
>
> Hi Peter and Kevin,
>
> On 9/25/19 1:24 PM, Peter Xu wrote:
> > On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
> >>> From: Peter Xu [mailto:pet...@redhat.com]
> >>> Sent: Wednesday,
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 25, 2019 2:57 PM
>
> On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote:
> > Hi Kevin,
> >
> > On 9/24/19 3:00 PM, Tian, Kevin wrote:
> > > > > > '---'
> > > > > > '---'
> > > > > >
> > > > >
Hi,
On 9/25/19 1:00 PM, Tian, Kevin wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, September 23, 2019 8:25 PM
If a dmar domain has DOMAIN_FLAG_FIRST_LEVEL_TRANS bit set
in its flags, IOMMU will use the first level page table for
translation. Hence, we need to map or unmap
37 matches
Mail list logo
