Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Jeremy Linton
Hi, I spun this up on my 8G model using the PFTF firmware from: https://github.com/pftf/RPi4/releases Which allows me to switch between ACPI/DT on the machine. In DT mode it works fine now, but with ACPI I continue to have failures unless I disable CMA via cma=0 on the kernel command line.

Re: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs

2020-07-08 Thread Brice Goglin
Le 06/07/2020 à 10:26, Jonathan Cameron a écrit : > On Sun, 5 Jul 2020 09:53:58 + > "Song Bao Hua (Barry Song)" wrote: > >>> -Original Message- >>> From: Will Deacon [mailto:w...@kernel.org] >>> Sent: Saturday, July 4, 2020 4:22 AM >>> To: Song Bao Hua (Barry Song) >>> Cc:

Re: add an API to check if a streamming mapping needs sync calls

2020-07-08 Thread Christoph Hellwig
On Mon, Jun 29, 2020 at 03:39:01PM +0200, Björn Töpel wrote: > On 2020-06-29 15:03, Christoph Hellwig wrote: >> Hi all, >> >> this series lifts the somewhat hacky checks in the XSK code if a DMA >> streaming mapping needs dma_sync_single_for_{device,cpu} calls to the >> DMA API. >> > > Thanks a

RE: [PATCH v4 04/15] vfio/type1: Report iommu nesting info to userspace

2020-07-08 Thread Liu, Yi L
Hi Alex, Eric asked if we will to have data strcut other than struct iommu_nesting_info type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not quit sure on it. I guess the answer may be not as VFIO's nesting support should based on IOMMU UAPI. how about your opinion?

Re: add an API to check if a streamming mapping needs sync calls

2020-07-08 Thread Daniel Borkmann
On 7/8/20 9:44 AM, Christoph Hellwig wrote: On Mon, Jun 29, 2020 at 03:39:01PM +0200, Björn Töpel wrote: On 2020-06-29 15:03, Christoph Hellwig wrote: Hi all, this series lifts the somewhat hacky checks in the XSK code if a DMA streaming mapping needs dma_sync_single_for_{device,cpu} calls to

Re: [PATCH] scatterlist: protect parameters of the sg_table related macros

2020-07-08 Thread Christoph Hellwig
On Tue, Jun 30, 2020 at 10:16:02AM +0200, Marek Szyprowski wrote: > Add brackets to protect parameters of the recently added sg_table related > macros from side-effects. Applied to the dma-mapping tree, thanks. ___ iommu mailing list

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Liu, Yi L
Hi Alex, > From: Liu, Yi L < yi.l@intel.com> > Sent: Friday, July 3, 2020 2:28 PM > > Hi Alex, > > > From: Alex Williamson > > Sent: Friday, July 3, 2020 5:19 AM > > > > On Wed, 24 Jun 2020 01:55:19 -0700 > > Liu Yi L wrote: > > > > > This patch allows user space to request PASID

Re: [PATCH net] xsk: remove cheap_dma optimization

2020-07-08 Thread Christoph Hellwig
On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote: > On 2020-06-28 18:16, Björn Töpel wrote: >> >> On 2020-06-27 09:04, Christoph Hellwig wrote: >>> On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote: Given there is roughly a ~5 weeks window at max where this removal

RE: [PATCH net] xsk: remove cheap_dma optimization

2020-07-08 Thread Song Bao Hua (Barry Song)
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Christoph Hellwig > Sent: Wednesday, July 8, 2020 6:50 PM > To: Robin Murphy > Cc: Björn Töpel ; Christoph Hellwig ; > Daniel Borkmann ; maxi...@mellanox.com; >

Re: [PATCH v10 5/5] iommu/arm-smmu: Add global/context fault implementation hooks

2020-07-08 Thread Jon Hunter
On 08/07/2020 06:00, Krishna Reddy wrote: > Add global/context fault hooks to allow vendor specific implementations > override default fault interrupt handlers. > > Update NVIDIA implementation to override the default global/context fault > interrupt handlers and handle interrupts across the

Re: [PATCH 0/4] iommu/arm-smmu-v3: Improve cmdq lock efficiency

2020-07-08 Thread John Garry
On 22/06/2020 18:28, John Garry wrote: Hi, Can you guys let me know if this is on the radar at all? I have been talking about this performance issue since Jan, and not getting anything really. thanks As mentioned in [0], the CPU may consume many cycles processing

Re: [PATCH net] xsk: remove cheap_dma optimization

2020-07-08 Thread Robin Murphy
On 2020-07-08 07:50, Christoph Hellwig wrote: On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote: On 2020-06-28 18:16, Bj�rn T�pel wrote: On 2020-06-27 09:04, Christoph Hellwig wrote: On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote: Given there is roughly a ~5

[PATCH 1/2] iommu/intel: Avoid SAC address trick for PCIe devices

2020-07-08 Thread Robin Murphy
For devices stuck behind a conventional PCI bus, saving extra cycles at 33MHz is probably fairly significant. However since native PCI Express is now the norm for high-performance devices, the optimisation to always prefer 32-bit addresses for the sake of avoiding DAC is starting to look rather

[PATCH 2/2] iommu/dma: Avoid SAC address trick for PCIe devices

2020-07-08 Thread Robin Murphy
As for the intel-iommu implementation, relegate the opportunistic attempt to allocate a SAC address to the domain of conventional PCI devices only, to avoid it increasingly causing far more performance issues than possible benefits on modern PCI Express systems. Signed-off-by: Robin Murphy ---

Re: [PATCH v10 3/5] iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage

2020-07-08 Thread Jon Hunter
On 08/07/2020 06:00, Krishna Reddy wrote: > NVIDIA's Tegra194 SoC has three ARM MMU-500 instances. > It uses two of the ARM MMU-500s together to interleave IOVA > accesses across them and must be programmed identically. > This implementation supports programming the two ARM MMU-500s > that must

Re: [PATCH 1/2] iommu/intel: Avoid SAC address trick for PCIe devices

2020-07-08 Thread Christoph Hellwig
Looks pretty sensible. > - if (!dmar_forcedac && dma_mask > DMA_BIT_MASK(32)) { > + if (!dmar_forcedac && dma_mask > DMA_BIT_MASK(32) && > + dev_is_pci(dev) && !pci_is_pcie(to_pci_dev(dev))) { The only thing I wonder is if it is worth to add a little helper for this check, but

Re: [PATCH v10 4/5] dt-bindings: arm-smmu: add binding for Tegra194 SMMU

2020-07-08 Thread Jon Hunter
On 08/07/2020 06:00, Krishna Reddy wrote: > Add binding for NVIDIA's Tegra194 SoC SMMU. > > Signed-off-by: Krishna Reddy > --- > .../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++ > 1 file changed, 18 insertions(+) > > diff --git

Re: [PATCH net] xsk: remove cheap_dma optimization

2020-07-08 Thread Christoph Hellwig
On Wed, Jul 08, 2020 at 07:57:23AM +, Song Bao Hua (Barry Song) wrote: > > int dma_map_batch_start(struct device *dev, size_t rounded_len, > > enum dma_data_direction dir, unsigned long attrs, dma_addr_t *addr); > > int dma_map_batch_add(struct device *dev, dma_addr_t *addr, struct page >

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Nicolas Saenz Julienne
Hi Jim, On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote: > Hi, > > I spun this up on my 8G model using the PFTF firmware from: > > https://github.com/pftf/RPi4/releases > > Which allows me to switch between ACPI/DT on the machine. In DT mode it > works fine now, Nice, would that

Re: [PATCH v6 03/10] iommu/mediatek: Use a u32 flags to describe different HW features

2020-07-08 Thread chao hao
Hi Matthias and Yingjoe, Thanks for your comments! On Mon, 2020-07-06 at 17:17 +0200, Matthias Brugger wrote: > > On 04/07/2020 03:16, Yingjoe Chen wrote: > > On Fri, 2020-07-03 at 12:41 +0800, Chao Hao wrote: > >> Given the fact that we are adding more and more plat_data bool values, > >> it

Re: [PATCH v10 2/5] iommu/arm-smmu: ioremap smmu mmio region before implementation init

2020-07-08 Thread Jon Hunter
On 08/07/2020 06:00, Krishna Reddy wrote: > ioremap smmu mmio region before calling into implementation init. > This is necessary to allow mapped address available during vendor > specific implementation init. > > Signed-off-by: Krishna Reddy > --- > drivers/iommu/arm-smmu.c | 8 > 1

Re: [PATCH v10 1/5] iommu/arm-smmu: move TLB timeout and spin count macros

2020-07-08 Thread Jon Hunter
On 08/07/2020 06:00, Krishna Reddy wrote: > Move TLB timeout and spin count macros to header file to > allow using the same from vendor specific implementations. > > Signed-off-by: Krishna Reddy > --- > drivers/iommu/arm-smmu.c | 3 --- > drivers/iommu/arm-smmu.h | 2 ++ > 2 files changed, 2

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Jeremy Linton
Hi, On 7/8/20 5:35 AM, Nicolas Saenz Julienne wrote: Hi Jim, On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote: Hi, I spun this up on my 8G model using the PFTF firmware from: https://github.com/pftf/RPi4/releases Which allows me to switch between ACPI/DT on the machine. In DT mode it

Re: [PATCH v4 3/5] iommu/uapi: Use named union for user data

2020-07-08 Thread Jacob Pan
On Wed, 8 Jul 2020 10:17:57 +0800 Lu Baolu wrote: > Hi Jacob, > > On 7/8/20 7:43 AM, Jacob Pan wrote: > > IOMMU UAPI data size is filled by the user space which must be > > validated by ther kernel. To ensure backward compatibility, user > > data can only be extended by either re-purpose

Re: [PATCH v4 1/5] docs: IOMMU user API

2020-07-08 Thread Jacob Pan
On Wed, 8 Jul 2020 10:07:13 +0800 Lu Baolu wrote: > Hi, > > On 7/8/20 7:43 AM, Jacob Pan wrote: > > +For UAPIs that are shared with in-kernel users, a wrapper function > > +is provided to distinguish the callers. For example, > > + > > +Userspace caller :: > > + > > + int

[PATCH 2/5] dma-mapping: inline the fast path dma-direct calls

2020-07-08 Thread Christoph Hellwig
Inline the single page map/unmap/sync dma-direct calls into the now out of line generic wrappers. This restores the behavior of a single function call that we had before moving the generic calls out of line. Besides the dma-mapping callers there are just a few callers in IOMMU drivers that have a

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Nicolas Saenz Julienne
On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote: > On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote: > > When allocating atomic DMA memory for a device, the dma-pool core > > queries __dma_direct_optimal_gfp_mask() to check which atomic pool to > > use. It turns

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-08 Thread Christoph Hellwig
On Wed, Jul 08, 2020 at 06:49:39PM +0200, Nicolas Saenz Julienne wrote: > There is no guarantee to CMA's placement, so allocating a zone specific > atomic pool from CMA might return memory from a completely different > memory zone. So stop using it. > > Fixes: c84dc6e68a1d ("dma-pool: add

[PATCH 3/5] dma-mapping: make support for dma ops optional

2020-07-08 Thread Christoph Hellwig
Avoid the overhead of the dma ops support for tiny builds that only use the direct mapping. Signed-off-by: Christoph Hellwig --- arch/alpha/Kconfig | 1 + arch/arm/Kconfig| 1 + arch/ia64/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/parisc/Kconfig

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Christoph Hellwig
On Wed, Jul 08, 2020 at 12:35:34PM +0200, Nicolas Saenz Julienne wrote: > > Which allows me to switch between ACPI/DT on the machine. In DT mode it > > works fine now, > > Nice, would that count as a Tested-by from you? > > > but with ACPI I continue to have failures unless I > > disable CMA

[PATCH 5/5] powerpc: use the generic dma_ops_bypass mode

2020-07-08 Thread Christoph Hellwig
Use the DMA API bypass mechanism for direct window mappings. This uses common code and speed up the direct mapping case by avoiding indirect calls just when not using dma ops at all. It also fixes a problem where the sync_* methods were using the bypass check for DMA allocations, but those are

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Christoph Hellwig
On Wed, Jul 08, 2020 at 06:00:35PM +0200, Nicolas Saenz Julienne wrote: > On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote: > > On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote: > > > When allocating atomic DMA memory for a device, the dma-pool core > > > queries

Re: [PATCH v3 1/5] docs: IOMMU user API

2020-07-08 Thread Jacob Pan
Hi Alex, All points below are taken. I have sent out v4 that addresses these feedbacks. Thanks for the review. Jacob On Tue, 7 Jul 2020 15:40:54 -0600 Alex Williamson wrote: > On Mon, 29 Jun 2020 16:05:18 -0700 > Jacob Pan wrote: > > > On Fri, 26 Jun 2020 16:19:23 -0600 > > Alex Williamson

[PATCH 1/5] dma-mapping: move the remaining DMA API calls out of line

2020-07-08 Thread Christoph Hellwig
For a long time the DMA API has been implemented inline in dma-mapping.h, but the function bodies can be quite large. Move them all out of line. This also removes all the dma_direct_* exports as those are just implementation details and should never be used by drivers directly. Signed-off-by:

[PATCH 4/5] dma-mapping: add a dma_ops_bypass flag to struct device

2020-07-08 Thread Christoph Hellwig
Several IOMMU drivers have a bypass mode where they can use a direct mapping if the devices DMA mask is large enough. Add generic support to the core dma-mapping code to do that to switch those drivers to a common solution. Signed-off-by: Christoph Hellwig --- include/linux/device.h | 8 +

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Robin Murphy
On 2020-07-08 16:36, Christoph Hellwig wrote: On Wed, Jul 08, 2020 at 12:35:34PM +0200, Nicolas Saenz Julienne wrote: Which allows me to switch between ACPI/DT on the machine. In DT mode it works fine now, Nice, would that count as a Tested-by from you? but with ACPI I continue to have

generic DMA bypass flag v4

2020-07-08 Thread Christoph Hellwig
Hi all, I've recently beeing chatting with Lu about using dma-iommu and per-device DMA ops in the intel IOMMU driver, and one missing feature in dma-iommu is a bypass mode where the direct mapping is used even when an iommu is attached to improve performance. The powerpc code already has a

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Christoph Hellwig
On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote: > When allocating atomic DMA memory for a device, the dma-pool core > queries __dma_direct_optimal_gfp_mask() to check which atomic pool to > use. It turns out the GFP flag returned is only an optimistic guess. > The pool

[PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-08 Thread Nicolas Saenz Julienne
There is no guarantee to CMA's placement, so allocating a zone specific atomic pool from CMA might return memory from a completely different memory zone. So stop using it. Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp mask") Reported-by: Jeremy Linton

[PATCH v7 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-08 Thread Jim Quinlan via iommu
The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking.

Re: [PATCH v2 4/6] drm/msm: Add support to create a local pagetable

2020-07-08 Thread Jordan Crouse
On Tue, Jul 07, 2020 at 12:36:42PM +0100, Robin Murphy wrote: > On 2020-06-26 21:04, Jordan Crouse wrote: > >Add support to create a io-pgtable for use by targets that support > >per-instance pagetables. In order to support per-instance pagetables the > >GPU SMMU device needs to have the

Re: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Alex Williamson
On Wed, 8 Jul 2020 08:16:16 + "Liu, Yi L" wrote: > Hi Alex, > > > From: Liu, Yi L < yi.l@intel.com> > > Sent: Friday, July 3, 2020 2:28 PM > > > > Hi Alex, > > > > > From: Alex Williamson > > > Sent: Friday, July 3, 2020 5:19 AM > > > > > > On Wed, 24 Jun 2020 01:55:19 -0700 > > >

[PATCH v7 00/12] PCI: brcmstb: enable PCIe for STB chips

2020-07-08 Thread Jim Quinlan via iommu
Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. v7: Commit: "device core: Introduce DMA range map, supplanting

Re: [PATCH v2 1/2] iommu: iommu_aux_at(de)tach_device() extension

2020-07-08 Thread Alex Williamson
On Wed, 8 Jul 2020 10:53:12 +0800 Lu Baolu wrote: > Hi Alex, > > Thanks a lot for your comments. Please check my reply inline. > > On 7/8/20 5:04 AM, Alex Williamson wrote: > > On Tue, 7 Jul 2020 09:39:56 +0800 > > Lu Baolu wrote: > > > >> The hardware assistant vfio mediated device is a

Re: [Freedreno] [PATCH v2 2/6] iommu/io-pgtable: Allow a pgtable implementation to skip TLB operations

2020-07-08 Thread Jordan Crouse
On Tue, Jul 07, 2020 at 07:58:18AM -0700, Rob Clark wrote: > On Tue, Jul 7, 2020 at 7:25 AM Rob Clark wrote: > > > > On Tue, Jul 7, 2020 at 4:34 AM Robin Murphy wrote: > > > > > > On 2020-06-26 21:04, Jordan Crouse wrote: > > > > Allow a io-pgtable implementation to skip TLB operations by

Re: [PATCH v4 04/15] vfio/type1: Report iommu nesting info to userspace

2020-07-08 Thread Alex Williamson
On Wed, 8 Jul 2020 08:08:40 + "Liu, Yi L" wrote: > Hi Alex, > > Eric asked if we will to have data strcut other than struct iommu_nesting_info > type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not > quit sure on it. I guess the answer may be not as VFIO's nesting

[PATCH] IOMMU DRIVERS: Replace HTTP links with HTTPS ones

2020-07-08 Thread Alexander A. Klimov
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:

Re: [PATCH] iommu/arm-smmu: Update impl quirks comment

2020-07-08 Thread Will Deacon
On Wed, 24 Jun 2020 11:24:51 +0100, Robin Murphy wrote: > The comment about implementation and integration quirks being > mutually-exclusive is out of date, and in fact the code is already > structured for the case it anticipates, so document that properly. Applied to will

Re: [PATCH v10 2/5] iommu/arm-smmu: ioremap smmu mmio region before implementation init

2020-07-08 Thread Nicolin Chen
On Tue, Jul 07, 2020 at 10:00:14PM -0700, Krishna Reddy wrote: > ioremap smmu mmio region before calling into implementation init. > This is necessary to allow mapped address available during vendor > specific implementation init. > > Signed-off-by: Krishna Reddy Reviewed-by: Nicolin Chen

Re: [PATCH v10 1/5] iommu/arm-smmu: move TLB timeout and spin count macros

2020-07-08 Thread Nicolin Chen
On Tue, Jul 07, 2020 at 10:00:13PM -0700, Krishna Reddy wrote: > Move TLB timeout and spin count macros to header file to > allow using the same from vendor specific implementations. > > Signed-off-by: Krishna Reddy Reviewed-by: Nicolin Chen ___

Re: [PATCH v10 3/5] iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage

2020-07-08 Thread Nicolin Chen
On Tue, Jul 07, 2020 at 10:00:15PM -0700, Krishna Reddy wrote: > NVIDIA's Tegra194 SoC has three ARM MMU-500 instances. > It uses two of the ARM MMU-500s together to interleave IOVA > accesses across them and must be programmed identically. > This implementation supports programming the two ARM

Re: [PATCH v10 5/5] iommu/arm-smmu: Add global/context fault implementation hooks

2020-07-08 Thread Nicolin Chen
On Tue, Jul 07, 2020 at 10:00:17PM -0700, Krishna Reddy wrote: > Add global/context fault hooks to allow vendor specific implementations > override default fault interrupt handlers. > > Update NVIDIA implementation to override the default global/context fault > interrupt handlers and handle

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-08 Thread Jeremy Linton
Hi, On 7/8/20 11:49 AM, Nicolas Saenz Julienne wrote: There is no guarantee to CMA's placement, so allocating a zone specific atomic pool from CMA might return memory from a completely different memory zone. So stop using it. Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map

Re: [PATCH v2 4/4] iommu/vt-d: Add page response ops support

2020-07-08 Thread Lu Baolu
Hi Kevin, On 7/6/20 9:47 AM, Tian, Kevin wrote: From: Lu Baolu Sent: Monday, July 6, 2020 8:26 AM After a page request is handled, software must response the device which raised the page request with the handling result. This is done through 'response' is a noun. Yes. the iommu

RE: [kbuild-all] Re: [PATCH v4 4/7] iommu/vt-d: Handle non-page aligned address

2020-07-08 Thread Li, Philip
> Subject: [kbuild-all] Re: [PATCH v4 4/7] iommu/vt-d: Handle non-page aligned > address > > Hi Jacob, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on iommu/next] > [also build test WARNING on linux/master linus/master v5.8-rc4 next-20200707] > [If

RE: [PATCH v4 04/15] vfio/type1: Report iommu nesting info to userspace

2020-07-08 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Thursday, July 9, 2020 3:30 AM > > On Wed, 8 Jul 2020 08:08:40 + > "Liu, Yi L" wrote: > > > Hi Alex, > > > > Eric asked if we will to have data strcut other than struct > > iommu_nesting_info > > type in the struct

Re: [PATCH] dma-pool: use single atomic pool for both DMA zones

2020-07-08 Thread Jeremy Linton
Hi, On 7/7/20 7:28 AM, Nicolas Saenz Julienne wrote: When allocating atomic DMA memory for a device, the dma-pool core queries __dma_direct_optimal_gfp_mask() to check which atomic pool to use. It turns out the GFP flag returned is only an optimistic guess. The pool selected might sometimes

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Liu, Yi L
Hi Alex, > Alex Williamson > Sent: Thursday, July 9, 2020 3:55 AM > > On Wed, 8 Jul 2020 08:16:16 + > "Liu, Yi L" wrote: > > > Hi Alex, > > > > > From: Liu, Yi L < yi.l@intel.com> > > > Sent: Friday, July 3, 2020 2:28 PM > > > > > > Hi Alex, > > > > > > > From: Alex Williamson > > >

Re: [PATCH v2 1/2] iommu: iommu_aux_at(de)tach_device() extension

2020-07-08 Thread Lu Baolu
Hi Alex, On 7/9/20 3:07 AM, Alex Williamson wrote: On Wed, 8 Jul 2020 10:53:12 +0800 Lu Baolu wrote: Hi Alex, Thanks a lot for your comments. Please check my reply inline. On 7/8/20 5:04 AM, Alex Williamson wrote: On Tue, 7 Jul 2020 09:39:56 +0800 Lu Baolu wrote: The hardware

Re: [PATCH v4 1/5] docs: IOMMU user API

2020-07-08 Thread Lu Baolu
Hi Jacob, On 7/8/20 11:29 PM, Jacob Pan wrote: On Wed, 8 Jul 2020 10:07:13 +0800 Lu Baolu wrote: Hi, On 7/8/20 7:43 AM, Jacob Pan wrote: +For UAPIs that are shared with in-kernel users, a wrapper function +is provided to distinguish the callers. For example, + +Userspace caller :: + + int

Re: [PATCH v2 0/8] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

2020-07-08 Thread Bjorn Andersson
On Fri 03 Jul 05:31 PDT 2020, Will Deacon wrote: > On Tue, Jun 09, 2020 at 03:40:18PM -0400, Jonathan Marek wrote: > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250. > > > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a > > few changes. Notably, the

Re: [PATCH v2 2/8] iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatibles

2020-07-08 Thread Bjorn Andersson
On Tue 09 Jun 12:40 PDT 2020, Jonathan Marek wrote: > Use the qcom implementation for IOMMU hardware on sm8150 and sm8250 SoCs. > > Signed-off-by: Jonathan Marek Reviewed-by: Bjorn Andersson Regards, Bjorn > --- > drivers/iommu/arm-smmu-impl.c | 4 +++- > 1 file changed, 3 insertions(+), 1

[PATCH 2/5] iommu/arm-smmu: Emulate bypass by using context banks

2020-07-08 Thread Bjorn Andersson
Some firmware found on various Qualcomm platforms traps writes to S2CR of type BYPASS and writes FAULT into the register. This prevents us from marking the streams for the display controller as BYPASS to allow continued scanout of the screen through the initialization of the ARM SMMU. This adds a

[PATCH 0/5] iommu/arm-smmu: Support maintaining bootloader mappings

2020-07-08 Thread Bjorn Andersson
Based on previous attempts and discussions this is the latest attempt at inheriting stream mappings set up by the bootloader, for e.g. boot splash or efifb. The first patch is an implementation of Robin's suggestion that we should just mark the relevant stream mappings as BYPASS. Relying on

[PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings

2020-07-08 Thread Bjorn Andersson
With many Qualcomm platforms not having functional S2CR BYPASS a temporary IOMMU domain, without translation, needs to be allocated in order to allow these memory transactions. Unfortunately the boot loader uses the first few context banks, so rather than overwriting a active bank the last

[PATCH 3/5] iommu/arm-smmu: Move SMR and S2CR definitions to header file

2020-07-08 Thread Bjorn Andersson
Expose the SMR and S2CR structs in the header file, to allow platform specific implementations to populate/initialize the smrs and s2cr arrays. Signed-off-by: Bjorn Andersson --- drivers/iommu/arm-smmu.c | 14 -- drivers/iommu/arm-smmu.h | 15 +++ 2 files changed, 15

[PATCH 1/5] iommu/arm-smmu: Make all valid stream mappings BYPASS

2020-07-08 Thread Bjorn Andersson
Turn all stream mappings marked as valid into BYPASS. This allows the platform specific implementation to configure stream mappings to match the boot loader's configuration for e.g. display to continue to function through the reset of the SMMU. Suggested-by: Robin Murphy Signed-off-by: Bjorn

[PATCH 4/5] iommu/arm-smmu-qcom: Consstently initialize stream mappings

2020-07-08 Thread Bjorn Andersson
Firmware that traps writes to S2CR to translate BYPASS into FAULT also ignores writes of type FAULT. As such booting with "disable_bypass" set will result in all S2CR registers left as configured by the bootloader. This has been seen to result in indeterministic results, as these mappings might

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Tian, Kevin
> From: Liu, Yi L > Sent: Thursday, July 9, 2020 8:32 AM > > Hi Alex, > > > Alex Williamson > > Sent: Thursday, July 9, 2020 3:55 AM > > > > On Wed, 8 Jul 2020 08:16:16 + > > "Liu, Yi L" wrote: > > > > > Hi Alex, > > > > > > > From: Liu, Yi L < yi.l@intel.com> > > > > Sent: Friday,

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Liu, Yi L
Hi Kevin, > From: Tian, Kevin > Sent: Thursday, July 9, 2020 9:57 AM > > > From: Liu, Yi L > > Sent: Thursday, July 9, 2020 8:32 AM > > > > Hi Alex, > > > > > Alex Williamson > > > Sent: Thursday, July 9, 2020 3:55 AM > > > > > > On Wed, 8 Jul 2020 08:16:16 + > > > "Liu, Yi L" wrote: > >

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Tian, Kevin
> From: Liu, Yi L > Sent: Thursday, July 9, 2020 10:08 AM > > Hi Kevin, > > > From: Tian, Kevin > > Sent: Thursday, July 9, 2020 9:57 AM > > > > > From: Liu, Yi L > > > Sent: Thursday, July 9, 2020 8:32 AM > > > > > > Hi Alex, > > > > > > > Alex Williamson > > > > Sent: Thursday, July 9,

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-08 Thread Liu, Yi L
Hi Kevin, > From: Tian, Kevin > Sent: Thursday, July 9, 2020 10:18 AM > > > From: Liu, Yi L > > Sent: Thursday, July 9, 2020 10:08 AM > > > > Hi Kevin, > > > > > From: Tian, Kevin > > > Sent: Thursday, July 9, 2020 9:57 AM > > > > > > > From: Liu, Yi L > > > > Sent: Thursday, July 9, 2020