Re: [PATCH v4 10/22] iommu: introduce device fault data

2018-05-21 Thread Jacob Pan
On Sun, 20 May 2018 08:17:43 + "Liu, Yi L" wrote: > Hi Jacob, > > > From: Jacob Pan [mailto:jacob.jun@linux.intel.com] > > Sent: Tuesday, April 17, 2018 5:49 AM > > include/linux/iommu.h | 102 > > +- > > 1 file

Re: [PATCH] iommu/io-pgtable-arm: Make allocations NUMA-aware

2018-05-21 Thread Will Deacon
On Mon, May 21, 2018 at 07:12:40PM +0100, Robin Murphy wrote: > We would generally expect pagetables to be read by the IOMMU more than > written by the CPU, so in NUMA systems it would be preferable to avoid > the IOMMU making cross-node pagetable walks if possible. We already have > a handle on

[PATCH] iommu/io-pgtable-arm: Make allocations NUMA-aware

2018-05-21 Thread Robin Murphy
We would generally expect pagetables to be read by the IOMMU more than written by the CPU, so in NUMA systems it would be preferable to avoid the IOMMU making cross-node pagetable walks if possible. We already have a handle on the IOMMU device for the sake of coherency management, so it's trivial

[RFC PATCH v2 09/12] mm/vmpressure: update usage of address zone modifiers

2018-05-21 Thread Huaisheng HS1 Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE

[RFC PATCH v2 08/12] drivers/block/zram/zram_drv: update usage of address zone modifiers

2018-05-21 Thread Huaisheng HS1 Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE

[RFC PATCH v2 07/12] fs/btrfs/extent_io: update usage of address zone modifiers

2018-05-21 Thread Huaisheng HS1 Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM). In function alloc_extent_state, it is obvious that __GFP_DMA is not the expecting zone type. ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing

[RFC PATCH v2 06/12] drivers/xen/swiotlb-xen: update usage of address zone modifiers

2018-05-21 Thread Huaisheng HS1 Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM). In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32 is not the expecting zone type. ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for

[RFC PATCH v2 12/12] arch/x86/include/asm/page.h: update usage of movableflags

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE, modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD. Signed-off-by: Huaisheng Ye Cc: Thomas Gleixner Cc: Ingo Molnar Cc:

[RFC PATCH v2 11/12] include/linux/highmem: update usage of movableflags

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE, modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD. Signed-off-by: Huaisheng Ye Cc: Kate Stewart Cc: Greg Kroah-Hartman

[RFC PATCH v2 10/12] mm/zsmalloc: update usage of address zone modifiers

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains

[RFC PATCH v2 05/12] include/linux/dma-mapping: update usage of address zone modifiers

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 04/12] drivers/iommu/amd_iommu: update usage of address zone modifiers

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 03/12] arch/x86/kernel/pci-calgary_64: update usage of address zone modifiers

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 02/12] arch/x86/kernel/amd_gart_64: update usage of address zone modifiers

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 01/12] include/linux/gfp.h: get rid of GFP_ZONE_TABLE/BAD

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone

[RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

2018-05-21 Thread Huaisheng Ye
From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone

Re: [RFC PATCH v2 05/12] include/linux/dma-mapping: update usage of address zone modifiers

2018-05-21 Thread Christoph Hellwig
On Mon, May 21, 2018 at 11:20:26PM +0800, Huaisheng Ye wrote: > From: Huaisheng Ye > > Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). > > ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP > bitmasks, the bottom three bits of GFP

Re: [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 16:58, Jonathan Cameron wrote: >> +static int vfio_iommu_bind_group(struct vfio_iommu *iommu, >> + struct vfio_group *group, >> + struct vfio_mm *vfio_mm) >> +{ >> +int ret; >> +bool enabled_sva = false; >> +struct

Re: [PATCH v2 17/40] iommu/arm-smmu-v3: Link domains and devices

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 17:07, Jonathan Cameron wrote: >> +++ b/drivers/iommu/arm-smmu-v3.c >> @@ -595,6 +595,11 @@ struct arm_smmu_device { >> struct arm_smmu_master_data { >> struct arm_smmu_device *smmu; >> struct arm_smmu_strtab_ent ste; >> + >> +struct arm_smmu_domain

Re: [PATCH v2 07/40] iommu: Add a page fault handler

2018-05-21 Thread Jean-Philippe Brucker
On 18/05/18 19:04, Jacob Pan wrote: >> +struct iopf_context { >> +struct device *dev; >> +struct iommu_fault_eventevt; >> +struct list_headhead; >> +}; >> + >> +struct iopf_group { >> +struct iopf_context last_fault; >> +

Re: [PATCH v2 07/40] iommu: Add a page fault handler

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 16:25, Jonathan Cameron wrote: > On Fri, 11 May 2018 20:06:08 +0100 > Jean-Philippe Brucker wrote: > >> Some systems allow devices to handle I/O Page Faults in the core mm. For >> example systems implementing the PCI PRI extension or Arm SMMU stall >>

Re: [PATCH v2 05/40] iommu/sva: Track mm changes with an MMU notifier

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 15:25, Jonathan Cameron wrote: >> + * already have been removed from the list. Check is someone is > > Check if someone... Ok Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 15:25, Jonathan Cameron wrote: >> +static struct io_mm * >> +io_mm_alloc(struct iommu_domain *domain, struct device *dev, >> +struct mm_struct *mm, unsigned long flags) >> +{ >> +int ret; >> +int pasid; >> +struct io_mm *io_mm; >> +struct iommu_sva_param *param

Re: [PATCH v2 02/40] iommu/sva: Bind process address spaces to devices

2018-05-21 Thread Jean-Philippe Brucker
On 17/05/18 14:10, Jonathan Cameron wrote: > On Fri, 11 May 2018 20:06:03 +0100 > Jean-Philippe Brucker wrote: > >> Add bind() and unbind() operations to the IOMMU API. Bind() returns a >> PASID that drivers can program in hardware, to let their devices access an

[PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings

2018-05-21 Thread Magnus Damm
From: Magnus Damm Update the IPMMU DT binding documentation to include the compat strings for the IPMMU devices included in the R-Car V3H and E3 SoCs. Signed-off-by: Magnus Damm --- Developed on top of

Re: [PATCH v11 0/4] iommu/arm-smmu: Add runtime pm/sleep support

2018-05-21 Thread Robin Murphy
On 22/03/18 10:22, Vivek Gautam wrote: This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains

Re: [PATCH] PCI: Do not enable PASID when End-to-End TLP is not supported

2018-05-21 Thread Sinan Kaya
+iommu folks. On 5/19/2018 12:52 PM, Sinan Kaya wrote: > A PCIe endpoint carries the process address space identifier (PASID) in > the TLP prefix as part of the memory read/write transaction. The address > information in the TLP is relevant only for a given PASID context. > > A translation agent

[PATCH v3] dma-debug: Check scatterlist segments

2018-05-21 Thread Robin Murphy
Drivers/subsystems creating scatterlists for DMA should be taking care to respect the scatter-gather limitations of the appropriate device, as described by dma_parms. A DMA API implementation cannot feasibly split a scatterlist into *more* entries than originally passed, so it is not well defined