Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

2020-07-22 Thread Sironi, Filippo via iommu
On Wed, 2020-07-22 at 14:19 +0200, j...@8bytes.org wrote: > > On Fri, Jul 17, 2020 at 03:15:43PM +, Sironi, Filippo wrote: > > I don't believe that we want to trust a userspace driver here, this > > may > > result in hosts becoming unstable because devices are asked to do > > things > > they

Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

2020-07-17 Thread Sironi, Filippo via iommu
On Fri, 2020-07-17 at 15:36 +0100, Robin Murphy wrote: > On 2020-07-17 14:22, Sironi, Filippo wrote: > > On Fri, 2020-07-17 at 10:47 +0100, Robin Murphy wrote: > > > > > > On 2020-07-17 10:20, Sebastian Ott via iommu wrote: > > > > Hello Joerg, > > > > > > > > On 2020-07-10 14:31, Joerg Roedel

Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

2020-07-17 Thread Sironi, Filippo via iommu
On Fri, 2020-07-17 at 10:47 +0100, Robin Murphy wrote: > > On 2020-07-17 10:20, Sebastian Ott via iommu wrote: > > Hello Joerg, > > > > On 2020-07-10 14:31, Joerg Roedel wrote: > > > On Wed, Jul 01, 2020 at 12:46:31AM +0200, Sebastian Ott wrote: > > > > The IVRS ACPI table specifies maximum

Re: [PATCH 6/6] iommu/amd: Lock code paths traversing protection_domain->dev_list

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 5/6] iommu/amd: Lock dev_data in attach/detach code paths

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 4/6] iommu/amd: Check for busy devices earlier in attach_device()

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 3/6] iommu/amd: Take domain->lock for complete attach/detach path

2019-09-25 Thread Sironi, Filippo via iommu
> 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. > >

Re: [PATCH 2/6] iommu/amd: Remove amd_iommu_devtable_lock

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 2/6] iommu/amd: Remove amd_iommu_devtable_lock

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 1/6] iommu/amd: Remove domain->updated

2019-09-25 Thread Sironi, Filippo via iommu
> 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

Re: [PATCH 4/5] iommu/amd: Hold the domain lock when calling iommu_map_page

2019-09-20 Thread Sironi, Filippo via iommu
> On 10. Sep 2019, at 19:49, Filippo Sironi wrote: > > iommu_map_page calls into __domain_flush_pages, which requires the > domain lock since it traverses the device list, which the lock protects. > > Signed-off-by: Filippo Sironi > --- > drivers/iommu/amd_iommu.c | 5 + > 1 file

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Sironi, Filippo via iommu
Hi Jacob, > On 30. Aug 2017, at 17:50, Jacob Pan wrote: > > On Mon, 28 Aug 2017 16:16:29 +0200 > Filippo Sironi via iommu wrote: > >> Previously, we were invalidating context cache and IOTLB globally when >> clearing one context

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Sironi, Filippo via iommu
Hi Joerg, > On 30. Aug 2017, at 15:31, Joerg Roedel wrote: > > Hi Filippo, > > please change the subject to: > > iommu/vt-d: Don't be too aggressive when clearing one context entry > > to follow the convention used in the iommu-tree. Another comment below. Will do. >