[PATCH v3] iommu/vt-d: consider real PCI device when checking if mapping is needed

2020-02-17 Thread Daniel Drake
From: Jon Derrick The PCI devices handled by intel-iommu may have a DMA requester on another bus, such as VMD subdevices needing to use the VMD endpoint. The real DMA device is now used for the DMA mapping, but one case was missed earlier: if the VMD device (and hence subdevices too) are under

RE: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)

2020-02-17 Thread Liu, Yi L
> From: Liu, Yi L > Sent: Friday, January 31, 2020 8:41 PM > To: Alex Williamson > Subject: RE: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free) > > > +static int vfio_iommu_type1_pasid_free(struct vfio_iommu *iommu, > > > +unsigned int pasid) > > > +{

Re: [PATCH 3/5] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

2020-02-17 Thread Lu Baolu
Hi Joerg, Thanks for doing this. On 2020/2/18 3:38, Joerg Roedel wrote: From: Joerg Roedel The attachment of deferred devices needs to happen before the check whether the device is identity mapped or not. Otherwise the check will return wrong results, cause warnings boot failures in kdump

Re: [PATCH 5/5] iommu/vt-d: Simplify check in identity_mapping()

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel The function only has one call-site and there it is never called with dummy or deferred devices. Simplify the check in the function to account for that. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar

Re: [PATCH 3/5] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel The attachment of deferred devices needs to happen before the check whether the device is identity mapped or not. Otherwise the check will return wrong results, cause warnings boot failures in kdump kernels, like WARNING: CPU: 0

Re: [PATCH 2/5] iommu/vt-d: Move deferred device attachment into helper function

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel Move the code that does the deferred device attachment into a separate helper function. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar ___ iommu mailing list

Re: [PATCH 4/5] iommu/vt-d: Remove deferred_attach_domain()

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel The function is now only a wrapper around find_domain(). Remove the function and call find_domain() directly at the call-sites. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar

Re: [PATCH 1/5] iommu/vt-d: Add attach_deferred() helper

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel Implement a helper function to check whether a device's attach process is deferred. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar ___ iommu mailing list

[PATCH 4/5] iommu/vt-d: Remove deferred_attach_domain()

2020-02-17 Thread Joerg Roedel
From: Joerg Roedel The function is now only a wrapper around find_domain(). Remove the function and call find_domain() directly at the call-sites. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iommu.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git

[PATCH 3/5] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

2020-02-17 Thread Joerg Roedel
From: Joerg Roedel The attachment of deferred devices needs to happen before the check whether the device is identity mapped or not. Otherwise the check will return wrong results, cause warnings boot failures in kdump kernels, like WARNING: CPU: 0 PID: 318 at

[PATCH 2/5] iommu/vt-d: Move deferred device attachment into helper function

2020-02-17 Thread Joerg Roedel
From: Joerg Roedel Move the code that does the deferred device attachment into a separate helper function. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iommu.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/intel-iommu.c

[PATCH 0/5] iommu/vt-d: Fix kdump boot with VT-d enabled

2020-02-17 Thread Joerg Roedel
Hi, booting into a crashdump kernel with Intel IOMMU enabled and configured into passthrough mode does not succeed with the current kernel. The reason is that the check for identity mappings happen before the check for deferred device attachments. That results in wrong results returned from

[PATCH 5/5] iommu/vt-d: Simplify check in identity_mapping()

2020-02-17 Thread Joerg Roedel
From: Joerg Roedel The function only has one call-site and there it is never called with dummy or deferred devices. Simplify the check in the function to account for that. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 1/5] iommu/vt-d: Add attach_deferred() helper

2020-02-17 Thread Joerg Roedel
From: Joerg Roedel Implement a helper function to check whether a device's attach process is deferred. Signed-off-by: Joerg Roedel --- drivers/iommu/intel-iommu.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel-iommu.c

Re: [PATCH v2] iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support

2020-02-17 Thread Robin Murphy
On 13/02/2020 9:49 pm, Rob Herring wrote: On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote: On 30/01/2020 3:06 pm, Auger Eric wrote: Hi Rob, On 1/17/20 10:16 PM, Rob Herring wrote: Arm SMMUv3.2 adds support for TLB range invalidate operations. Support for range invalidate is determined

Re: [PATCH v2] iommu/arm-smmu-v3: Batch ATC invalidation commands

2020-02-17 Thread Jean-Philippe Brucker
On Thu, Feb 13, 2020 at 02:56:00PM -0600, Rob Herring wrote: > Similar to commit 2af2e72b18b4 ("iommu/arm-smmu-v3: Defer TLB > invalidation until ->iotlb_sync()"), build up a list of ATC invalidation > commands and submit them all at once to the command queue instead of > one-by-one. > > As there

Re: [RFC PATCH] iommu/iova: Support limiting IOVA alignment

2020-02-17 Thread Robin Murphy
On 14/02/2020 8:30 pm, Liam Mark wrote: When the IOVA framework applies IOVA alignment it aligns all IOVAs to the smallest PAGE_SIZE order which is greater than or equal to the requested IOVA size. We support use cases that requires large buffers (> 64 MB in size) to be allocated and mapped in

Re: [RFC PATCH] iommu/iova: Add a best-fit algorithm

2020-02-17 Thread Robin Murphy
On 14/02/2020 11:06 pm, Isaac J. Manjarres wrote: From: Liam Mark Using the best-fit algorithm, instead of the first-fit algorithm, may reduce fragmentation when allocating IOVAs. What kind of pathological allocation patterns make that a serious problem? Is there any scope for simply

Re: [RFC PATCH] iommu/dma: Allow drivers to reserve an iova range

2020-02-17 Thread Robin Murphy
On 17/02/2020 8:01 am, Christoph Hellwig wrote: On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote: From: Liam Mark Some devices have a memory map which contains gaps or holes. In order for the device to have as much IOVA space as possible, allow its driver to inform the

Re: [PATCH 02/11] PCI: Add ats_supported host bridge flag

2020-02-17 Thread Jean-Philippe Brucker
On Sat, Feb 15, 2020 at 03:10:47PM -0600, Bjorn Helgaas wrote: > On Thu, Feb 13, 2020 at 05:50:40PM +0100, Jean-Philippe Brucker wrote: > > Each vendor has their own way of describing whether a host bridge > > supports ATS. The Intel and AMD ACPI tables selectively enable or > > disable ATS per

Re: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

2020-02-17 Thread Jerry Snitselaar
On Mon Feb 17 20, Robin Murphy wrote: On 16/02/2020 10:11 pm, Jerry Snitselaar wrote: On Fri Feb 14 20, Robin Murphy wrote: Hi Jerry, On 2020-02-14 8:13 pm, Jerry Snitselaar wrote: Hi Will, On a gigabyte system with Cavium CN8xx, when doing a fio test against an nvme drive we are seeing the

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

2020-02-17 Thread Robin Murphy
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote: On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

2020-02-17 Thread Michael S. Tsirkin
On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote: > On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote: > > On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: > > > On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > > > > On Fri, Feb 14, 2020 at

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

2020-02-17 Thread Robin Murphy
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote: On 14/02/2020 4:04 pm, Jean-Philippe

Re: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

2020-02-17 Thread Robin Murphy
On 16/02/2020 10:11 pm, Jerry Snitselaar wrote: On Fri Feb 14 20, Robin Murphy wrote: Hi Jerry, On 2020-02-14 8:13 pm, Jerry Snitselaar wrote: Hi Will, On a gigabyte system with Cavium CN8xx, when doing a fio test against an nvme drive we are seeing the following: [  637.161194] arm-smmu

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

2020-02-17 Thread Michael S. Tsirkin
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: > On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > > On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote: > > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > > With the built-in

Re: [PATCH 03/11] PCI: OF: Check whether the host bridge supports ATS

2020-02-17 Thread Jean-Philippe Brucker
On Thu, Feb 13, 2020 at 12:26:46PM -0600, Rob Herring wrote: > On Thu, Feb 13, 2020 at 10:52 AM Jean-Philippe Brucker > wrote: > > > > Copy the ats-supported flag into the pci_host_bridge structure. > > > > Signed-off-by: Jean-Philippe Brucker > > --- > >

Re: arm64 iommu groups issue

2020-02-17 Thread John Garry
Right, and even worse is that it relies on the port driver even existing at all. All this iommu group assignment should be taken outside device driver probe paths. However we could still consider device links for sync'ing the SMMU and each device probing. Yes, we should get that for DT

Re: [PATCH 2/2] iommu/mediatek: add support for MT8167

2020-02-17 Thread Yong Wu
Hi Fabien, Thanks very much for your patch. On Mon, 2020-02-17 at 09:15 +0800, CK Hu wrote: > +Yong.Wu. > > On Fri, 2020-01-03 at 17:26 +0100, Fabien Parent wrote: > > Add support for the IOMMU on MT8167 > > > > Signed-off-by: Fabien Parent > > --- > > drivers/iommu/mtk_iommu.c | 11

Re: [PATCH 2/3] PCI: Add DMA configuration for virtual platforms

2020-02-17 Thread Jean-Philippe Brucker
On Fri, Feb 14, 2020 at 05:03:16PM +, Robin Murphy wrote: > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > Hardware platforms usually describe the IOMMU topology using either > > device-tree pointers or vendor-specific ACPI tables. For virtual > > platforms that don't provide a

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

2020-02-17 Thread Jean-Philippe Brucker
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote: > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > With the built-in topology description in place, x86 platforms can now > > > use the virtio-iommu. > > >

Re: [RFC PATCH] iommu/iova: Add a best-fit algorithm

2020-02-17 Thread Christoph Hellwig
On Fri, Feb 14, 2020 at 03:06:42PM -0800, Isaac J. Manjarres wrote: > From: Liam Mark > > Using the best-fit algorithm, instead of the first-fit > algorithm, may reduce fragmentation when allocating > IOVAs. As we like to say in standards groups: may also implies may not. Please provide

Re: [RFC PATCH] iommu/dma: Allow drivers to reserve an iova range

2020-02-17 Thread Christoph Hellwig
On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote: > From: Liam Mark > > Some devices have a memory map which contains gaps or holes. > In order for the device to have as much IOVA space as possible, > allow its driver to inform the DMA-IOMMU layer that it should > not allocate