Re: [PATCH v11 1/3] ACPI/IORT: Add msi address regions reservation helper

2017-12-14 Thread Lorenzo Pieralisi
On Thu, Dec 14, 2017 at 12:17:50PM +, Shameerali Kolothum Thodi wrote: > Hi Lorenzo, > > > -Original Message- > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > > Sent: Thursday, December 14, 2017 11:48 AM > > To: Shameerali Kolothum Thodi

[PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

2017-12-14 Thread Shameer Kolothum
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI

[PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

2017-12-14 Thread Shameer Kolothum
On some platforms msi parent address regions have to be excluded from normal IOVA allocation in that they are detected and decoded in a HW specific way by system components and so they cannot be considered normal IOVA address space. Add a helper function that retrieves ITS address regions - the

[PATCH v12 2/3] iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation

2017-12-14 Thread Shameer Kolothum
Modified iommu_dma_get_resv_regions() to include GICv3 ITS region on ACPI based ARM platfiorms which may require HW MSI reservations. Signed-off-by: Shameer Kolothum Reviewed-by: Robin Murphy --- drivers/iommu/dma-iommu.c | 8 +++-

[PATCH v12 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07

2017-12-14 Thread Shameer Kolothum
The HiSilicon erratum 161010801 describes the limitation of HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings for MSI transactions. PCIe controller on these platforms has to differentiate the MSI payload against other DMA payload and has to modify the MSI payload. This makes it

[PATCH v2 2/4] iommu/io-pgtable-arm: Support 52-bit physical address

2017-12-14 Thread Robin Murphy
Bring io-pgtable-arm in line with the ARMv8.2-LPA feature allowing 52-bit physical addresses when using the 64KB translation granule. This will be supported by SMMUv3.1. Tested-by: Nate Watterson Signed-off-by: Robin Murphy --- v2: Fix

[PATCH v2 1/4] iommu/arm-smmu-v3: Clean up address masking

2017-12-14 Thread Robin Murphy
Before trying to add the SMMUv3.1 support for 52-bit addresses, make things bearable by cleaning up the various address mask definitions to use GENMASK_ULL() consistently. The fact that doing so reveals (and fixes) a latent off-by-one in Q_BASE_ADDR_MASK only goes to show what a jolly good idea it

[PATCH v2 4/4] iommu/arm-smmu-v3: Support 52-bit virtual address

2017-12-14 Thread Robin Murphy
Stage 1 input addresses are effectively 64-bit in SMMUv3 anyway, so really all that's involved is letting io-pgtable know the appropriate upper bound for T0SZ. Tested-by: Nate Watterson Signed-off-by: Robin Murphy --- v2: No change

[PATCH v2 3/4] iommu/arm-smmu-v3: Support 52-bit physical address

2017-12-14 Thread Robin Murphy
Implement SMMUv3.1 support for 52-bit physical addresses. Since a 52-bit OAS implies 64KB translation granule support, permitting level 1 block entries there is simple, and the rest is just extending address fields. Tested-by: Nate Watterson Signed-off-by: Robin Murphy

[PATCH v2 0/4] SMMU 52-bit address support

2017-12-14 Thread Robin Murphy
Hi all, Here's a (hopefully final) update of 52-bit SMMU support. The only material changes from v1[1] are a small cosmetic tweak to patch #1, and correction of the silly error in patch #2 as reported by Nate in testing. Robin. [1]

Re: [PATCH] iommu/arm-smmu-v3: Don't free page table ops twice

2017-12-14 Thread Robin Murphy
On 14/12/17 11:03, Jean-Philippe Brucker wrote: Kasan reports a double free when finalise_stage_fn fails: the io_pgtable ops are freed by arm_smmu_domain_finalise and then again by arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure. It might be a tiny bit more consistent

RE: [PATCH v11 1/3] ACPI/IORT: Add msi address regions reservation helper

2017-12-14 Thread Shameerali Kolothum Thodi
Hi Lorenzo, > -Original Message- > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > Sent: Thursday, December 14, 2017 11:48 AM > To: Shameerali Kolothum Thodi > Cc: robin.mur...@arm.com; marc.zyng...@arm.com; will.dea...@arm.com; >

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

2017-12-14 Thread Raj, Ashok
Hi Bob On Thu, Dec 14, 2017 at 02:07:38PM +0800, Bob Liu wrote: > On 2017/12/14 11:38, Lu Baolu wrote: > We already have an existing MMU notifiers for userspace updates, > however we lack the same thing for kernel page table updates. To > >> Sorry, I didn't get which situation need

Re: [PATCH] iommu/vt-d: Fix shift overflow in qi_flush_dev_iotlb

2017-12-14 Thread kbuild test robot
Hi Alex, I love your patch! Yet something to improve: [auto build test ERROR on v4.15-rc3] [also build test ERROR on next-20171214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alex

Re: [PATCH] iommu/vt-d: Fix shift overflow in qi_flush_dev_iotlb

2017-12-14 Thread Peter Xu
On Wed, Dec 13, 2017 at 11:31:02AM -0600, Hook, Gary wrote: > On 12/13/2017 11:15 AM, Alex Williamson wrote: > > On Wed, 13 Dec 2017 10:41:47 -0600 > > "Hook, Gary" wrote: > > > > > On 12/13/2017 9:58 AM, Alex Williamson wrote: > > > > On Wed, 13 Dec 2017 15:13:55 +0800 > > > >

[PATCH] iommu/arm-smmu-v3: Don't free page table ops twice

2017-12-14 Thread Jean-Philippe Brucker
Kasan reports a double free when finalise_stage_fn fails: the io_pgtable ops are freed by arm_smmu_domain_finalise and then again by arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure. Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices")

Re: [PATCH v11 1/3] ACPI/IORT: Add msi address regions reservation helper

2017-12-14 Thread Lorenzo Pieralisi
On Wed, Dec 13, 2017 at 11:58:28AM +, Shameer Kolothum wrote: > On some platforms msi parent address regions have to be excluded from > normal IOVA allocation in that they are detected and decoded in a HW > specific way by system components and so they cannot be considered normal > IOVA