[PATCH] dma-direct: Fix data truncation in dma_direct_get_required_mask()

2020-04-06 Thread Kishon Vijay Abraham I via iommu
The upper 32-bit physical address gets truncated inadvertently when dma_direct_get_required_mask() invokes phys_to_dma_direct(). This results in dma_addressing_limited() return incorrect value when used in platforms with LPAE enabled. Fix it here by explicitly type casting 'max_pfn' to phys_addr_t

Re: arm-smmu-v3 high cpu usage for NVMe

2020-04-06 Thread John Garry
On 02/04/2020 13:10, John Garry wrote: On 18/03/2020 20:53, Will Deacon wrote: As for arm_smmu_cmdq_issue_cmdlist(), I do note that during the testing our batch size is 1, so we're not seeing the real benefit of the batching. I can't help but think that we could improve this code to try to

Re: [PATCH 05/10] iommu/ioasid: Create an IOASID set for host SVA use

2020-04-06 Thread Jacob Pan
Hi Jean, On Wed, 1 Apr 2020 15:53:16 +0200 Jean-Philippe Brucker wrote: > On Wed, Mar 25, 2020 at 10:55:26AM -0700, Jacob Pan wrote: > > Bare metal SVA allocates IOASIDs for native process addresses. This > > should be separated from VM allocated IOASIDs thus under its own > > set. > > > >

Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device

2020-04-06 Thread Christoph Hellwig
On Mon, Apr 06, 2020 at 11:25:09PM +1000, Alexey Kardashevskiy wrote: > >> Do you see any serious problem with this approach? Thanks! > > > > Do you have a link to the whole branch? The github UI is unfortunately > > unusable for that (or I'm missing something). > > The UI shows the branch but

Re: [PATCH 06/10] iommu/ioasid: Convert to set aware allocations

2020-04-06 Thread Jacob Pan
On Sat, 28 Mar 2020 06:40:58 + "Tian, Kevin" wrote: > > From: Jacob Pan > > Sent: Saturday, March 28, 2020 1:42 AM > > > > On Fri, 27 Mar 2020 09:54:11 + > > "Tian, Kevin" wrote: > > > > > > From: Jacob Pan > > > > Sent: Thursday, March 26, 2020 1:55 AM > > > > > > > > The current

Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG_MAX

2020-04-06 Thread Nicolin Chen
On Mon, Apr 06, 2020 at 02:48:13PM +0100, Robin Murphy wrote: > On 2020-04-05 1:51 am, Nicolin Chen wrote: > > The default segment_boundary_mask was set to DMA_BIT_MAKS(32) > > a decade ago by referencing SCSI/block subsystem, as a 32-bit > > mask was good enough for most of the devices. > > > >

Re: [PATCH 03/10] iommu/ioasid: Introduce per set allocation APIs

2020-04-06 Thread Jacob Pan
On Wed, 1 Apr 2020 15:47:45 +0200 Jean-Philippe Brucker wrote: > On Wed, Mar 25, 2020 at 10:55:24AM -0700, Jacob Pan wrote: > > IOASID set defines a group of IDs that share the same token. The > > ioasid_set concept helps to do permission checking among users as > > in the current code. > > > >

[RFC/RFT][PATCH v2] dma-mapping: set default segment_boundary_mask to ULONG_MAX

2020-04-06 Thread Nicolin Chen
The default segment_boundary_mask was set to DMA_BIT_MAKS(32) a decade ago by referencing SCSI/block subsystem, as a 32-bit mask was good enough for most of the devices. Now more and more drivers set dma_masks above DMA_BIT_MAKS(32) while only a handful of them call dma_set_seg_boundary(). This

Re: [PATCH 00/19] [PULL REQUEST] iommu/vt-d: patches for v5.7

2020-04-06 Thread Lu Baolu
On 2020/4/6 21:36, Christoph Hellwig wrote: On Sun, Apr 05, 2020 at 04:30:34PM +0800, Lu Baolu wrote: Hi Joerg, Below patches have been piled up for v5.7. They enable below features: Err, this is not the time for 5.7 features that haven't been in linux-next before 5.6 was released.

RE: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-06 Thread Tian, Kevin
> From: Alex Williamson > Sent: Saturday, April 4, 2020 1:26 AM [...] > > > > + if (!pasid_cap.control_reg.paside) { > > > > + pr_debug("%s: its PF's PASID capability is not > > > > enabled\n", > > > > + dev_name(>pdev->dev)); > > > > + ret

[RFC PATCH] iommu/amd: fix a race in fetch_pte()

2020-04-06 Thread Qian Cai
fetch_pte() could race with increase_address_space() because it held no lock from iommu_unmap_page(). On the CPU that runs fetch_pte() it could see a stale domain->pt_root and a new increased domain->mode from increase_address_space(). As the result, it could trigger invalid accesses later on. Fix

RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)

2020-04-06 Thread Tian, Kevin
> From: Alex Williamson > Sent: Saturday, April 4, 2020 1:50 AM [...] > > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > > > > index 9e843a1..298ac80 100644 > > > > --- a/include/uapi/linux/vfio.h > > > > +++ b/include/uapi/linux/vfio.h > > > > @@ -794,6 +794,47 @@ struct

RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)

2020-04-06 Thread Tian, Kevin
> From: Alex Williamson > Sent: Friday, April 3, 2020 11:14 PM > > On Fri, 3 Apr 2020 05:58:55 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Friday, April 3, 2020 1:50 AM > > > > > > On Sun, 22 Mar 2020 05:31:58 -0700 > > > "Liu, Yi L" wrote: > > > > > > > From: Liu

RE: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

2020-04-06 Thread Yoshihiro Shimoda
Hi again, > I'm guessing we should add the following flush_work for > deferred_probe_timeout_work(). > # Sorry, I didn't test this for some reasons yet though... > > + /* wait for the deferred probe timeout workqueue to finish */ > + if (driver_deferred_probe_timeout > 0) > +

RE: [PATCH v10 04/11] vfio/pci: Add VFIO_REGION_TYPE_NESTED region type

2020-04-06 Thread Liu, Yi L
Hi Eric, > From: Auger Eric > Sent: Wednesday, April 1, 2020 9:31 PM > To: Liu, Yi L ; eric.auger@gmail.com; > iommu@lists.linux- > Subject: Re: [PATCH v10 04/11] vfio/pci: Add VFIO_REGION_TYPE_NESTED region > type > > Hi Yi, > > On 4/1/20 3:18 PM, Liu, Yi L wrote: > > Hi Eric, > > > >

RE: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

2020-04-06 Thread Yoshihiro Shimoda
Hi John, Geert, > From: John Stultz, Sent: Saturday, April 4, 2020 1:19 PM > > On Fri, Apr 3, 2020 at 4:47 AM Geert Uytterhoeven > wrote: > > On Thu, Apr 2, 2020 at 7:27 PM John Stultz wrote: > > > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda > > > wrote: > > > > > > > > I found an issue

Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG_MAX

2020-04-06 Thread Robin Murphy
On 2020-04-05 1:51 am, Nicolin Chen wrote: The default segment_boundary_mask was set to DMA_BIT_MAKS(32) a decade ago by referencing SCSI/block subsystem, as a 32-bit mask was good enough for most of the devices. Now more and more drivers set dma_masks above DMA_BIT_MAKS(32) while only a

Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device

2020-04-06 Thread Christoph Hellwig
On Fri, Apr 03, 2020 at 07:38:11PM +1100, Alexey Kardashevskiy wrote: > > > On 26/03/2020 12:26, Alexey Kardashevskiy wrote: > > > > > > On 25/03/2020 19:37, Christoph Hellwig wrote: > >> On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote: > > This is for persistent

Re: [PATCH 00/19] [PULL REQUEST] iommu/vt-d: patches for v5.7

2020-04-06 Thread Christoph Hellwig
On Sun, Apr 05, 2020 at 04:30:34PM +0800, Lu Baolu wrote: > Hi Joerg, > > Below patches have been piled up for v5.7. They enable below > features: Err, this is not the time for 5.7 features that haven't been in linux-next before 5.6 was released. ___

Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device

2020-04-06 Thread Alexey Kardashevskiy
On 06/04/2020 21:50, Christoph Hellwig wrote: > On Fri, Apr 03, 2020 at 07:38:11PM +1100, Alexey Kardashevskiy wrote: >> >> >> On 26/03/2020 12:26, Alexey Kardashevskiy wrote: >>> >>> >>> On 25/03/2020 19:37, Christoph Hellwig wrote: On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey