Re: [PATCH v3 0/5] iommu/arm-smmu: add support for non-pci devices

On 2015/7/21 18:30, Robin Murphy wrote: On 21/07/15 08:30, Zhen Lei wrote: Changelog: v2 - v3: 1. add support for pci device hotplug, which missed in patch v2. 2. only support #iommu-cells = 1, add corresponding description in arm,smmu-v3.txt. 3. add function find_smmu_by_device which

Re: [PATCH v2 7/7] iommu/arm-smmu: Support non-PCI devices with SMMUv3

On 2016/6/14 23:16, Will Deacon wrote: > [adding ThunderTown, since he might be able to test this for us] OK. I'm so glad to do it. > > On Fri, Jun 03, 2016 at 06:15:42PM +0100, Robin Murphy wrote: >> With the device <-> stream ID relationship suitably abstracted and >> of_xlate() hooked up,

Re: [PATCH v2 7/7] iommu/arm-smmu: Support non-PCI devices with SMMUv3

ing device tst_smmu to group 0 //It's already late. On 2016/6/15 9:22, Leizhen (ThunderTown) wrote: > > > On 2016/6/14 23:16, Will Deacon wrote: >> [adding ThunderTown, since he might be able to test this for us] > > OK. I'm so glad t

Re: [PATCH v2 7/7] iommu/arm-smmu: Support non-PCI devices with SMMUv3

On 2016/6/17 17:14, Robin Murphy wrote: > On 17/06/16 02:54, Leizhen (ThunderTown) wrote: >> Hi, >> I only applied these patch series on lastest 4.7-rc3, is there any patches I >> missed? >> According to my test, it seems can not work. The problem is: > > Than

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/23 19:42, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Keep these four variables type consistent with the paramters of function >> __alloc_and_insert_iova_range and the members of struct iova: >> >> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

On 2017/3/23 21:01, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Reserve the first granule size memory(start at start_pfn) as boundary >> iova, to make sure that iovad->cached32_node can not be NULL in future. >> Meanwhile, changed the assignment of iovad->cached32_node from

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

Because the problem of my email-server, all patches sent to Joerg Roedel <j...@8bytes.org> failed. So I repost this email again. On 2017/3/24 11:43, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 21:01, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/24 10:27, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 19:42, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Keep these four variables type consistent with the paramters of function >>> __alloc_and_insert_iova_range and the members

Re: [PATCH 2/7] iommu/iova: cut down judgement times

On 2017/3/23 20:11, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Below judgement can only be satisfied at the last time, which produced 2N >> judgements(suppose N times failed, 0 or 1 time successed) in vain. >> >> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { >>

Re: [PATCH 0/4] Optimise 64-bit IOVA allocations

On 2017/7/19 18:23, Robin Murphy wrote: > On 19/07/17 09:37, Ard Biesheuvel wrote: >> On 18 July 2017 at 17:57, Robin Murphy wrote: >>> Hi all, >>> >>> In the wake of the ARM SMMU optimisation efforts, it seems that certain >>> workloads (e.g. storage I/O with large

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/7/26 19:08, Joerg Roedel wrote: > Hi Robin. > > On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote: >> Hi all, >> >> In the wake of the ARM SMMU optimisation efforts, it seems that certain >> workloads (e.g. storage I/O with large scatterlists) probably remain quite >> heavily

Re: [PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit

On 2017/7/19 23:07, kbuild test robot wrote: > Hi Zhen, > > [auto build test WARNING on iommu/next] > [also build test WARNING on v4.13-rc1] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/6/28 17:32, Will Deacon wrote: > Hi Zhen Lei, > > Nate (CC'd), Robin and I have been working on something very similar to > this series, but this patch is different to what we had planned. More below. > > On Mon, Jun 26, 2017 at 09:38:46PM +0800, Zhen Lei wrote: >> Because all TLBI

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21,

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/9 11:24, Ganapatrao Kulkarni wrote: > On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown) > <thunder.leiz...@huawei.com> wrote: >> >> >> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: >>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)

Re: [PATCH 0/5] arm-smmu: performance optimization

On 2017/8/17 22:36, Will Deacon wrote: > Thunder, Nate, Robin, > > On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: >> I described the optimization more detail in patch 1 and 2, and patch 3-5 are >> the implementation on arm-smmu/arm-smmu-v3 of patch 2. >> >> Patch 1 is v2. In v1, I

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/20 19:35, Robin Murphy wrote: > On 20/06/17 12:04, Zhen Lei wrote: >> This function is protected by spinlock, and the latter will do memory >> barrier implicitly. So that we can safely use writel_relaxed. In fact, the >> dmb operation will lengthen the time protected by lock, which

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/21 17:08, Will Deacon wrote: > On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >> On 2017/6/20 19:35, Robin Murphy wrote: >>> On 20/06/17 12:04, Zhen Lei wrote: >>>> This function is protected by spinlock, and the latter will do memo

Re: [PATCH v2 0/8] io-pgtable lock removal

On 2017/6/26 21:12, John Garry wrote: > >>> >>> I saw Will has already sent the pull request. But, FWIW, we are seeing >>> roughly the same performance as v1 patchset. For PCI NIC, Zhou again >>> found performance drop goes from ~15->8% with SMMU enabled, and for >>> integrated storage

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

On 2017/6/26 21:29, Leizhen (ThunderTown) wrote: > > > On 2017/6/21 17:08, Will Deacon wrote: >> On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >>> On 2017/6/20 19:35, Robin Murphy wrote: >>>> On 20/06/17 12:04, Zhen Lei wro

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/7/31 19:42, Robin Murphy wrote: > Hi Nate, > > On 29/07/17 04:57, Nate Watterson wrote: >> Hi Robin, >> I am seeing a crash when performing very basic testing on this series >> with a Mellanox CX4 NIC. I dug into the crash a bit, and think this >> patch is the culprit, but this rcache

Re: [PATCH v2 0/3] arm-smmu: performance optimization

On 2017/9/19 12:31, Nate Watterson wrote: > Hi Leizhen, > > On 9/12/2017 9:00 AM, Zhen Lei wrote: >> v1 -> v2: >> base on (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") >> >> Zhen Lei (3): >>iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock >>

Re: [PATCH 2/2] iommu: Introduce Interface for IOMMU TLB Flushing

On 2017/8/23 21:50, Joerg Roedel wrote: > From: Joerg Roedel > > With the current IOMMU-API the hardware TLBs have to be > flushed in every iommu_ops->unmap() call-back. > > For unmapping large amounts of address space, like it > happens when a KVM domain with assigned

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/8/4 3:41, Nate Watterson wrote: > Hi Robin, > > On 7/31/2017 7:42 AM, Robin Murphy wrote: >> Hi Nate, >> >> On 29/07/17 04:57, Nate Watterson wrote: >>> Hi Robin, >>> I am seeing a crash when performing very basic testing on this series >>> with a Mellanox CX4 NIC. I dug into the crash

Re: [PATCH 2/2] iommu: Introduce Interface for IOMMU TLB Flushing

On 2017/8/29 19:19, Robin Murphy wrote: > On 29/08/17 03:53, Leizhen (ThunderTown) wrote: > [...] >>> -size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t >>> size) >>> +static size_t __iommu_unmap(struct iommu_domain *domain, >>

Re: [PATCH v2 2/3] iommu/arm-smmu-v3: add support for unmap an iova range with only one tlb sync

On 2017/10/18 21:00, Will Deacon wrote: > On Tue, Sep 12, 2017 at 09:00:37PM +0800, Zhen Lei wrote: >> This patch is base on: >> (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") >> >> Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval >> ".unmap"

Re: [PATCH v2 1/3] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/10/18 20:58, Will Deacon wrote: > Hi Thunder, > > On Tue, Sep 12, 2017 at 09:00:36PM +0800, Zhen Lei wrote: >> Because all TLBI commands should be followed by a SYNC command, to make >> sure that it has been completely finished. So we can just add the TLBI >> commands into the queue,

Re: [PATCH 0/7] add non-strict mode support for arm-smmu-v3

On 2018/6/1 14:50, Leizhen (ThunderTown) wrote: > > > On 2018/5/31 22:25, Robin Murphy wrote: >> On 31/05/18 14:49, Hanjun Guo wrote: >>> Hi Robin, >>> >>> On 2018/5/31 19:24, Robin Murphy wrote: >>>> On 31/05/18 08:42, Zhen Lei wrote: >

Re: [PATCH v2 0/5] add non-strict mode support for arm-smmu-v3

On 2018/6/11 19:05, Jean-Philippe Brucker wrote: > Hi Zhen Lei, > > On 10/06/18 12:07, Zhen Lei wrote: >> v1 -> v2: >> Use the lowest bit of the io_pgtable_ops.unmap's iova parameter to pass the >> strict mode: >> 0, IOMMU_STRICT; >> 1, IOMMU_NON_STRICT; >> Treat 0 as IOMMU_STRICT, so that

Re: [PATCH 5/7] iommu/dma: add support for non-strict mode

On 2018/6/2 1:51, kbuild test robot wrote: > Hi Zhen, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on linus/master] > [also build test WARNING on v4.17-rc7 next-20180601] > [cannot apply to iommu/next] > [if your patch is applied to the wrong git

Re: [PATCH 5/7] iommu/dma: add support for non-strict mode

On 2018/5/31 21:04, Robin Murphy wrote: > On 31/05/18 08:42, Zhen Lei wrote: >> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad >> capable call domain->ops->flush_iotlb_all to flush TLB. >> 2. Define a new iommu capable: IOMMU_CAP_NON_STRICT, which used to indicate

Re: [PATCH 4/7] iommu/amd: make sure TLB to be flushed before IOVA freed

On 2018/5/31 21:04, Robin Murphy wrote: > On 31/05/18 08:42, Zhen Lei wrote: >> Although the mapping has already been removed in the page table, it maybe >> still exist in TLB. Suppose the freed IOVAs is reused by others before the >> flush operation completed, the new user can not correctly

Re: [PATCH 1/7] iommu/dma: fix trival coding style mistake

On 2018/5/31 21:03, Robin Murphy wrote: > On 31/05/18 08:42, Zhen Lei wrote: >> The static function iova_reserve_iommu_regions is only called by function >> iommu_dma_init_domain, and the 'if (!dev)' check in iommu_dma_init_domain >> affect it only, so we can safely move the check into it. I

Re: [PATCH 3/7] iommu: prepare for the non-strict mode support

On 2018/5/31 21:04, Robin Murphy wrote: > On 31/05/18 08:42, Zhen Lei wrote: >> In common, a IOMMU unmap operation follow the below steps: >> 1. remove the mapping in page table of the specified iova range >> 2. execute tlbi command to invalid the mapping which is cached in TLB >> 3. wait for

Re: [PATCH 0/7] add non-strict mode support for arm-smmu-v3

On 2018/5/31 22:25, Robin Murphy wrote: > On 31/05/18 14:49, Hanjun Guo wrote: >> Hi Robin, >> >> On 2018/5/31 19:24, Robin Murphy wrote: >>> On 31/05/18 08:42, Zhen Lei wrote: In common, a IOMMU unmap operation follow the below steps: 1. remove the mapping in page table of the

Re: [PATCH v3 2/6] iommu/dma: add support for non-strict mode

On 2018/7/25 6:01, Robin Murphy wrote: > On 2018-07-12 7:18 AM, Zhen Lei wrote: >> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad >> capable call domain->ops->flush_iotlb_all to flush TLB. >> 2. Add a new iommu capability: IOMMU_CAP_NON_STRICT, which used to

Re: [PATCH v3 4/6] iommu/io-pgtable-arm: add support for non-strict mode

On 2018/7/25 6:25, Robin Murphy wrote: > On 2018-07-12 7:18 AM, Zhen Lei wrote: >> To support the non-strict mode, now we only tlbi and sync for the strict >> mode. But for the non-leaf case, always follow strict mode. >> >> Use the lowest bit of the iova parameter to pass the strict mode: >>

Re: [PATCH v3 0/6] add non-strict mode support for arm-smmu-v3

On 2018/7/25 5:51, Robin Murphy wrote: > On 2018-07-12 7:18 AM, Zhen Lei wrote: >> v2 -> v3: >> Add a bootup option "iommu_strict_mode" to make the manager can choose which >> mode to be used. The first 5 patches have not changed. >> +iommu_strict_mode=[arm-smmu-v3] >> +0 -

Re: [PATCH v3 6/6] iommu/arm-smmu-v3: add bootup option "iommu_strict_mode"

On 2018/7/25 6:46, Robin Murphy wrote: > On 2018-07-12 7:18 AM, Zhen Lei wrote: >> Because the non-strict mode introduces a vulnerability window, so add a >> bootup option to make the manager can choose which mode to be used. The >> default mode is IOMMU_STRICT. >> >> Signed-off-by: Zhen Lei

Re: [PATCH v3 0/6] add non-strict mode support for arm-smmu-v3

On 2018/7/26 22:16, Robin Murphy wrote: > On 2018-07-26 4:44 AM, Leizhen (ThunderTown) wrote: >> >> >> On 2018/7/25 5:51, Robin Murphy wrote: >>> On 2018-07-12 7:18 AM, Zhen Lei wrote: >>>> v2 -> v3: Add a bootup option "iommu_strict_mo

Re: [PATCH 1/1] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/8 18:12, Will Deacon wrote: > Hi Thunder, > > On Mon, Aug 06, 2018 at 08:31:29PM +0800, Zhen Lei wrote: >> The condition "(int)(VAL - sync_idx) >= 0" to break loop in function >> __arm_smmu_sync_poll_msi requires that sync_idx must be increased >> monotonously according to the

Re: [PATCH 1/1] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/9 16:49, Will Deacon wrote: > On Thu, Aug 09, 2018 at 09:30:51AM +0800, Leizhen (ThunderTown) wrote: >> On 2018/8/8 18:12, Will Deacon wrote: >>> On Mon, Aug 06, 2018 at 08:31:29PM +0800, Zhen Lei wrote: >>>> The condition "(int)(VAL - sync_i

Re: [PATCH v4 2/5] iommu/dma: add support for non-strict mode

On 2018/8/9 18:46, Robin Murphy wrote: > On 06/08/18 13:27, Zhen Lei wrote: >> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad >> capable call domain->ops->flush_iotlb_all to flush TLB. >> 2. During the iommu domain initialization phase, base on domain->non_strict

Re: [PATCH v4 3/5] iommu/io-pgtable-arm: add support for non-strict mode

On 2018/8/9 18:54, Robin Murphy wrote: > On 06/08/18 13:27, Zhen Lei wrote: >> To support the non-strict mode, now we only tlbi and sync for the strict >> mode. But for the non-leaf case, always follow strict mode. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/iommu/io-pgtable-arm.c | 27

Re: [PATCH v3 1/2] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/16 2:08, John Garry wrote: > On 15/08/2018 14:00, Will Deacon wrote: >> On Wed, Aug 15, 2018 at 01:26:31PM +0100, Robin Murphy wrote: >>> On 15/08/18 11:23, Zhen Lei wrote: The condition "(int)(VAL - sync_idx) >= 0" to break loop in function __arm_smmu_sync_poll_msi requires

Re: [PATCH v3 1/2] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/15 20:26, Robin Murphy wrote: > On 15/08/18 11:23, Zhen Lei wrote: >> The condition "(int)(VAL - sync_idx) >= 0" to break loop in function >> __arm_smmu_sync_poll_msi requires that sync_idx must be increased >> monotonously according to the sequence of the CMDs in the cmdq. >> >> But

Re: [PATCH v4 4/5] iommu/arm-smmu-v3: add support for non-strict mode

On 2018/8/9 19:06, Robin Murphy wrote: > On 06/08/18 13:27, Zhen Lei wrote: >> Dynamically choose strict or non-strict mode for page table config based >> on the iommu domain type. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/iommu/arm-smmu-v3.c | 7 ++- >> 1 file changed, 6

Re: [PATCH v3 4/6] iommu/io-pgtable-arm: add support for non-strict mode

On 2018/8/6 9:32, Yang, Shunyong wrote: > Hi, Robin, > > On 2018/7/26 22:37, Robin Murphy wrote: >> On 2018-07-26 8:20 AM, Leizhen (ThunderTown) wrote: >>> On 2018/7/25 6:25, Robin Murphy wrote: >>>> On 2018-07-12 7:18 AM, Zhen Lei wrote: >>>>&g

Re: [PATCH v4 5/5] iommu/arm-smmu-v3: add bootup option "arm_iommu"

On 2018/8/9 19:08, Robin Murphy wrote: > On 06/08/18 13:27, Zhen Lei wrote: >> Add a bootup option to make the system manager can choose which mode to >> be used. The default mode is strict. >> >> Signed-off-by: Zhen Lei >> --- >> Documentation/admin-guide/kernel-parameters.txt | 9 +

Re: [PATCH v3 1/2] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/16 17:27, Robin Murphy wrote: > On 2018-08-16 10:18 AM, Will Deacon wrote: >> On Thu, Aug 16, 2018 at 04:21:17PM +0800, Leizhen (ThunderTown) wrote: >>> On 2018/8/15 20:26, Robin Murphy wrote: >>>> On 15/08/18 11:23, Zhen Lei wrote: >>>>&g

Re: [PATCH v5 3/5] iommu/io-pgtable-arm: add support for non-strict mode

On 2018/8/23 1:52, Robin Murphy wrote: > On 15/08/18 02:28, Zhen Lei wrote: >> To support the non-strict mode, now we only tlbi and sync for the strict >> mode. But for the non-leaf case, always follow strict mode. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/iommu/io-pgtable-arm.c | 20

Re: [PATCH v5 5/5] iommu/arm-smmu-v3: add bootup option "iommu.non_strict"

On 2018/8/23 1:02, Robin Murphy wrote: > On 15/08/18 02:28, Zhen Lei wrote: >> Add a bootup option to make the system manager can choose which mode to >> be used. The default mode is strict. >> >> Signed-off-by: Zhen Lei >> --- >> Documentation/admin-guide/kernel-parameters.txt | 13

Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Poll for CMD_SYNC outside cmdq lock

On 2017/10/18 22:04, Robin Murphy wrote: > Even without the MSI trick, we can still do a lot better than hogging > the entire queue while it drains. All we actually need to do for the > necessary guarantee of completion is wait for our particular command to > have been consumed, and as long as

Re: [PATCH v4 2/2] iommu/arm-smmu-v3: avoid redundant CMD_SYNCs if possible

On 2018/8/30 19:18, John Garry wrote: > On 19/08/2018 08:51, Zhen Lei wrote: >> spin_unlock_irqrestore(>cmdq.lock, flags); > > I find something like this adds support for combining CMD_SYNC commands for > regular polling mode: > > @@ -569,6 +569,7 @@ struct arm_smmu_device { >

Re: [PATCH v3 1/2] iommu/arm-smmu-v3: fix unexpected CMD_SYNC timeout

On 2018/8/19 15:02, Leizhen (ThunderTown) wrote: > > > On 2018/8/16 17:27, Robin Murphy wrote: >> On 2018-08-16 10:18 AM, Will Deacon wrote: >>> On Thu, Aug 16, 2018 at 04:21:17PM +0800, Leizhen (ThunderTown) wrote: >>>> On 2018/8/15 20:26, Robin Murphy

Re: [PATCH 1/1] iommu/arm-smmu-v3: prevent any devices access to memory without registration

On 2018/7/13 1:01, Will Deacon wrote: > On Thu, Jul 12, 2018 at 05:28:43PM +0800, Zhen Lei wrote: >> Stream bypass is not security. A malicious device can be hot plugged >> without match any drivers, but it can access to any memory. So change to >> disable bypass by default. >> >>

Re: [PATCH 1/1] iommu/amd: make sure TLB to be flushed before IOVA freed

Hi Joerg: Can you take a look at it? On 2018/6/6 10:18, Zhen Lei wrote: > Although the mapping has already been removed in the page table, it maybe > still exist in TLB. Suppose the freed IOVAs is reused by others before the > flush operation completed, the new user can not correctly access to

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/16 1:21, Will Deacon wrote: > On Mon, Oct 15, 2018 at 04:36:16PM +0800, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040 GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> >> The standard GITS_TRANSLATER register in ITS is

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/15 20:46, Andrew Murray wrote: > Hi Zhen, > > On Mon, Oct 15, 2018 at 04:36:16PM +0800, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040 GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> >> The standard GITS_TRANSLATER

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/15 19:17, John Garry wrote: > On 15/10/2018 09:36, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> > > Can you add a better opening than the ITS translation register map? OK > >> The

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/15 21:52, Robin Murphy wrote: > On 15/10/18 09:36, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> >> The standard GITS_TRANSLATER register in ITS is only 4 bytes, but Hisilicon >> expands

Re: [PATCH v2 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/30 1:59, Will Deacon wrote: > On Sat, Oct 20, 2018 at 03:36:54PM +0800, Zhen Lei wrote: >> The standard GITS_TRANSLATER register in ITS is only 4 bytes, but >> Hisilicon expands the next 4 bytes to carry some IMPDEF information. That >> means, total 8 bytes data will be written to

Re: [PATCH v2 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/30 17:26, John Garry wrote: > On 30/10/2018 01:52, Leizhen (ThunderTown) wrote: >> >> >> On 2018/10/30 1:59, Will Deacon wrote: >>> On Sat, Oct 20, 2018 at 03:36:54PM +0800, Zhen Lei wrote: >>>> The standard GITS_TRANSLATER register in ITS i

Re: [PATCH v5 0/5] add non-strict mode support for arm-smmu-v3

On 2018/9/13 1:12, Robin Murphy wrote: > On 12/09/18 17:57, Will Deacon wrote: >> Hi all, >> >> On Wed, Aug 15, 2018 at 09:28:25AM +0800, Zhen Lei wrote: >>> v4 -> v5: >>> 1. change the type of global variable and struct member named "non_strict" >>> from >>> "int" to "bool". >>> 2. cancel

Re: [PATCH 1/1] iommu: Add config option to set lazy mode as default

On 2019/3/22 22:42, John Garry wrote: > On 22/03/2019 14:11, Zhen Lei wrote: > >> This allows the default behaviour to be controlled by a kernel config >> option instead of changing the command line for the kernel to include >> "iommu.strict=0" on ARM64 where this is desired. >> >> This is

Re: [PATCH v3 1/1] iommu: Add config option to set lazy mode as default

On 2019/3/29 10:54, Zhen Lei wrote: > This allows the default behaviour to be controlled by a kernel config > option instead of changing the command line for the kernel to include > "iommu.strict=0" on ARM64 where this is desired. > > This is similar to CONFIG_IOMMU_DEFAULT_PASSTHROUGH. > >

Re: [PATCH v2 1/1] iommu: Add config option to set lazy mode as default

On 2019/3/28 3:18, Robin Murphy wrote: > On 27/03/2019 15:00, Zhen Lei wrote: >> This allows the default behaviour to be controlled by a kernel config >> option instead of changing the command line for the kernel to include >> "iommu.strict=0" on ARM64 where this is desired. >> >> This is

Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled

Hi Will, On 2019/4/4 23:30, Will Deacon wrote: > Hi Zhen Lei, > > On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote: >> v1 --> v2: >> 1. Drop part2. Now, we only use the SMMUv3 hardware feature STE.config=0b000 >> (Report abort to device, no event recorded) to suppress the event messages

Re: [PATCH v4 0/6] normalize IOMMU dma mode boot options

On 2019/4/8 9:14, Hanjun Guo wrote: > Hi Zhen, > > On 2019/4/7 20:41, Zhen Lei wrote: >> As Robin Murphy's suggestion: >> "It's also not necessarily obvious to the user how this interacts with >> IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it >> would be better to

Re: [PATCH v4 0/6] normalize IOMMU dma mode boot options

On 2019/4/8 14:32, Thomas Gleixner wrote: > On Mon, 8 Apr 2019, Leizhen (ThunderTown) wrote: >>> >>> This will break systems using boot options as now, and I think >>> this is unacceptable. If you want to do so, just introduce iommu.dma_mode >>> on top of

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

On 2019/2/26 20:36, Hanjun Guo wrote: > Hi Jean, > > On 2019/1/31 22:55, Jean-Philippe Brucker wrote: >> Hi, >> >> On 31/01/2019 13:52, Zhen Lei wrote: >>> Currently, many peripherals are faster than before. For example, the top >>> speed of the older netcard is 10Gb/s, and now it's more than

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

On 2019/3/1 19:07, Jean-Philippe Brucker wrote: > Hi Leizhen, > > On 01/03/2019 04:44, Leizhen (ThunderTown) wrote: >> >> >> On 2019/2/26 20:36, Hanjun Guo wrote: >>> Hi Jean, >>> >>> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:

Re: [PATCH 0/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel

Hi Will, Robin: Do you have time to review these patches? Hope you can give me some opinions. On 2019/2/19 15:54, Zhen Lei wrote: > This patch series include two parts: > 1. Patch1-2 use dummy STE tables with "ste abort" hardware feature to abort > unexpected >devices accessing. For more

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

On 2019/3/4 23:52, Robin Murphy wrote: > On 02/03/2019 06:12, Leizhen (ThunderTown) wrote: >> >> >> On 2019/3/1 19:07, Jean-Philippe Brucker wrote: >>> Hi Leizhen, >>> >>> On 01/03/2019 04:44, Leizhen (ThunderTown) wrote: >>>> &

Re: [PATCH 2/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel

It seems that the picture is too big, I change it from jpg to png. On 2019/3/1 17:02, Leizhen (ThunderTown) wrote: > Hi All, > I drew a flowchart, hope this can help you to understand my method. > > On 2019/2/19 15:54, Zhen Lei wrote: >> To reduce the ris

Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode

On 2019/4/16 23:21, Will Deacon wrote: > On Fri, Apr 12, 2019 at 02:11:31PM +0100, Robin Murphy wrote: >> On 12/04/2019 11:26, John Garry wrote: >>> On 09/04/2019 13:53, Zhen Lei wrote: +static int __init iommu_dma_mode_setup(char *str) +{ +if (!str) +goto fail;

Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled

On 2019/4/16 17:14, Will Deacon wrote: > On Mon, Apr 08, 2019 at 10:31:47AM +0800, Leizhen (ThunderTown) wrote: >> On 2019/4/4 23:30, Will Deacon wrote: >>> On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote: >>>> v1 --> v2: >>>> 1. Drop part2.

Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options

On 2019/5/30 20:20, John Garry wrote: > On 30/05/2019 04:48, Zhen Lei wrote: >> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the >> opportunity to set {lazy|strict} mode as default at build time. Then put >> the three config options in an choice, make people can only

Re: [PATCH v7 1/1] iommu: enhance IOMMU dma mode build options

On 2019/5/27 22:21, Joerg Roedel wrote: > Hi Zhen Lei, > > On Mon, May 20, 2019 at 09:59:47PM +0800, Zhen Lei wrote: >> arch/ia64/kernel/pci-dma.c| 2 +- >> arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++- >> arch/s390/pci/pci_dma.c | 2 +- >>

Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options

On 2019/5/31 18:42, John Garry wrote: > -config IOMMU_DEFAULT_PASSTHROUGH -    bool "IOMMU passthrough by default" +choice +    prompt "IOMMU default DMA mode" depends on IOMMU_API -    help -  Enable passthrough by default, removing the need to

Re: [PATCH v8 2/7] x86/dma: use IS_ENABLED() to simplify the code

On 2019/6/12 13:16, Borislav Petkov wrote: > On Thu, May 30, 2019 at 11:48:26AM +0800, Zhen Lei wrote: >> This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to >> improve readablity. > > Avoid having "This patch" or "This commit" in the commit message. It is > tautologically

Re: [PATCH v6 1/1] iommu: enhance IOMMU dma mode build options

On 2019/5/8 17:42, John Garry wrote: > On 18/04/2019 14:57, Zhen Lei wrote: >> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the >> opportunity to set {lazy|strict} mode as default at build time. Then put >> the three config options in an choice, make people can only

Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled

On 2019/4/17 9:39, Leizhen (ThunderTown) wrote: > > > On 2019/4/16 17:14, Will Deacon wrote: >> On Mon, Apr 08, 2019 at 10:31:47AM +0800, Leizhen (ThunderTown) wrote: >>> On 2019/4/4 23:30, Will Deacon wrote: >>>> On Mon, Mar 18, 2019 at 09:12:41PM +0

Re: [PATCH v6 0/1] iommu: enhance IOMMU dma mode build options

Hi all, Can anybody review or comment? On 2019/4/18 21:57, Zhen Lei wrote: > v5 --> v6: > 1. give up adding boot option iommu.dma_mode > > v4 --> v5: > As Hanjun and Thomas Gleixner's suggestion: > 1. Keep the old ARCH specific boot options no change. > 2. Keep build option

Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode

On 2019/4/12 19:16, Joerg Roedel wrote: > On Tue, Apr 09, 2019 at 08:53:03PM +0800, Zhen Lei wrote: >> +static int __init iommu_dma_mode_setup(char *str) >> +{ >> +if (!str) >> +goto fail; >> + >> +if (!strncmp(str, "passthrough", 11)) >> +iommu_default_dma_mode

Re: [PATCH] iommu/arm-smmu-v3: add nr_ats_masters to avoid unnecessary operations

On 2019/8/14 1:10, Will Deacon wrote: > On Mon, Aug 12, 2019 at 11:42:17AM +0100, John Garry wrote: >> On 01/08/2019 13:20, Zhen Lei wrote: >>> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a >>> smmu domain does not contain any ats master, the operations of >>>

Re: [PATCH] iommu/arm-smmu-v3: add nr_ats_masters to avoid unnecessary operations

On 2019/8/14 19:14, Will Deacon wrote: > Hi, > > I've been struggling with the memory ordering requirements here. More below. > > On Thu, Aug 01, 2019 at 08:20:40PM +0800, Zhen Lei wrote: >> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a >> smmu domain does not

Re: [PATCH v2 2/2] iommu/arm-smmu-v3: add nr_ats_masters for quickly check

On 2019/8/15 23:23, Will Deacon wrote: > On Thu, Aug 15, 2019 at 01:44:39PM +0800, Zhen Lei wrote: >> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a >> smmu domain does not contain any ats master, the operations of >> arm_smmu_atc_inv_to_cmd() and lock protection in

Re: [PATCH v2 0/2] iommu/iova: enhance the rcache optimization

Hi all, Can anyone help review it? On 2019/8/15 20:11, Zhen Lei wrote: > v1 --> v2 > 1. I did not chagne the patches but added this cover-letter. > 2. Add a batch of reviewers base on >9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation") > 3. I described the problem I

Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

On 2019/8/23 16:37, Will Deacon wrote: > On Fri, Aug 23, 2019 at 04:06:52PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2019/8/23 15:50, Will Deacon wrote: >>> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote: >>>> v2 --> v3: >>>

Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

On 2019/8/23 16:06, Leizhen (ThunderTown) wrote: > > > On 2019/8/23 15:50, Will Deacon wrote: >> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote: >>> v2 --> v3: >>> As Will Deacon's suggestion, I changed the lock type of >>> arm_smmu_do

Re: [RESEND PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

On 2020/11/17 18:25, John Garry wrote: > Leizhen reported some time ago that IOVA performance may degrade over time > [0], but unfortunately his solution to fix this problem was not given > attention. > > To summarize, the issue is that as time goes by, the CPU rcache and depot > rcache

Re: [RESEND PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

On 2020/12/9 19:22, John Garry wrote: > On 09/12/2020 09:13, Leizhen (ThunderTown) wrote: >> >> >> On 2020/11/17 18:25, John Garry wrote: >>> Leizhen reported some time ago that IOVA performance may degrade over time >>> [0], but unfortunately his sol

Re: [RESEND PATCH v3 2/4] iommu/iova: Avoid double-negatives in magazine helpers

On 2020/12/9 19:39, John Garry wrote: > On 09/12/2020 09:03, Leizhen (ThunderTown) wrote: >> >> >> On 2020/11/17 18:25, John Garry wrote: >>> A similar crash to the following could be observed if initial CPU rcache >>> magazine allocations fail in init_i

Re: [PATCH 2/2] Revert "iommu/arm-smmu-v3: Don't reserve implementation defined register space"

On 2021/1/20 23:02, Robin Murphy wrote: > On 2021-01-19 01:59, Zhen Lei wrote: >> This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046. >> >> This problem has been fixed by another patch. The original method had side >> effects, it was not mapped to the user-specified resource size. The

Re: [PATCH 1/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

On 2021/1/20 23:54, Robin Murphy wrote: > On 2021-01-20 14:14, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/20 21:27, Robin Murphy wrote: >>> On 2021-01-20 09:26, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2021/1/20 11:37,

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

On 2021/1/22 21:00, Robin Murphy wrote: > On 2021-01-22 12:51, Will Deacon wrote: >> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >>> When changing from a set of pages/smaller blocks to a larger block for an >>> address, the software should follow the sequence of BBML processing.

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

On 2021/1/22 20:51, Will Deacon wrote: > On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >> When changing from a set of pages/smaller blocks to a larger block for an >> address, the software should follow the sequence of BBML processing. >> >> When changing from a block to a set of

Re: [PATCH 2/2] Revert "iommu/arm-smmu-v3: Don't reserve implementation defined register space"

On 2021/1/21 20:50, Robin Murphy wrote: > On 2021-01-21 02:04, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/20 23:02, Robin Murphy wrote: >>> On 2021-01-19 01:59, Zhen Lei wrote: >>>> This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

On 2021/1/22 21:00, Robin Murphy wrote: > On 2021-01-22 12:51, Will Deacon wrote: >> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >>> When changing from a set of pages/smaller blocks to a larger block for an >>> address, the software should follow the sequence of BBML processing.

  1   2   >