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
> >
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,
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,
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
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
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
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, September 25, 2019 12:31 PM
On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote:
intel_mmmap_range(domain,
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:
> > > > >
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:
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_default(void)
> +{
> + struct dmar_drhd_unit *drhd;
> + struct intel_iommu *iommu;
> +
> +
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:
> > > > > '---'
> > > > > '---'
> > > > >
> > > > > This patch series only aims to achieve the first goal, a.k.a using
> > first goal? then what are other
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
> 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
> 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,
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
> 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
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
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
---
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
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
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
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")
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")
> 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.
>
>
> 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
> 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
> 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
>
> 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
> 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
> 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
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
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
33 matches
Mail list logo
