* [PATCHv2 0/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-18 2:51 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm, Bjorn Andersson, Douglas Anderson, Krishna Reddy, Thierry Reding, Tomasz Figa, Sai Prakash Ranjan Currently for iommu_unmap() of large scatter-gather list with page size elements, the majority of time is spent in flushing of partial walks in __arm_lpae_unmap() which is a VA based TLB invalidation invalidating page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support range based invalidations like on arm-smmu-v3.2. For example: to unmap a 32MB scatter-gather list with page size elements (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge overhead. So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate the entire context for partial walk flush on select few platforms where cost of over-invalidation is less than unmap latency using the newly introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for non-strict mode given its all about over-invalidation saving time on individual unmaps and non-deterministic generally. For this example of 32MB scatter-gather list unmap, this results in just 16 ASID based TLB invalidations (TLBIASIDs) as opposed to 8192 TLBIVAs thereby increasing the performance of unmaps drastically. Test on QTI SM8150 SoC for 10 iterations of iommu_{map_sg}/unmap: (average over 10 iterations) Before this optimization: size iommu_map_sg iommu_unmap 4K 2.067 us 1.854 us 64K 9.598 us 8.802 us 1M 148.890 us 130.718 us 2M 305.864 us 67.291 us 12M 1793.604 us 390.838 us 16M 2386.848 us 518.187 us 24M 3563.296 us 775.989 us 32M 4747.171 us 1033.364 us After this optimization: size iommu_map_sg iommu_unmap 4K 1.723 us 1.765 us 64K 9.880 us 8.869 us 1M 155.364 us 135.223 us 2M 303.906 us 5.385 us 12M 1786.557 us 21.250 us 16M 2391.890 us 27.437 us 24M 3570.895 us 39.937 us 32M 4755.234 us 51.797 us This is further reduced once the map/unmap_pages() support gets in which will result in just 1 TLBIASID as compared to 16 TLBIASIDs. Real world data also shows big difference in unmap performance as below: There were reports of camera frame drops because of high overhead in iommu unmap without this optimization because of frequent unmaps issued by camera of about 100MB/s taking more than 100ms thereby causing frame drops. Changes in v2: * Add a quirk to choose tlb_flush_all in partial walk flush * Set the quirk for QTI SoC implementation Sai Prakash Ranjan (3): iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list iommu/arm-smmu-qcom: Set IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC impl drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 11 +++++++++++ drivers/iommu/io-pgtable-arm.c | 3 ++- include/linux/io-pgtable.h | 11 +++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCHv2 0/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-18 2:51 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Currently for iommu_unmap() of large scatter-gather list with page size elements, the majority of time is spent in flushing of partial walks in __arm_lpae_unmap() which is a VA based TLB invalidation invalidating page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support range based invalidations like on arm-smmu-v3.2. For example: to unmap a 32MB scatter-gather list with page size elements (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge overhead. So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate the entire context for partial walk flush on select few platforms where cost of over-invalidation is less than unmap latency using the newly introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for non-strict mode given its all about over-invalidation saving time on individual unmaps and non-deterministic generally. For this example of 32MB scatter-gather list unmap, this results in just 16 ASID based TLB invalidations (TLBIASIDs) as opposed to 8192 TLBIVAs thereby increasing the performance of unmaps drastically. Test on QTI SM8150 SoC for 10 iterations of iommu_{map_sg}/unmap: (average over 10 iterations) Before this optimization: size iommu_map_sg iommu_unmap 4K 2.067 us 1.854 us 64K 9.598 us 8.802 us 1M 148.890 us 130.718 us 2M 305.864 us 67.291 us 12M 1793.604 us 390.838 us 16M 2386.848 us 518.187 us 24M 3563.296 us 775.989 us 32M 4747.171 us 1033.364 us After this optimization: size iommu_map_sg iommu_unmap 4K 1.723 us 1.765 us 64K 9.880 us 8.869 us 1M 155.364 us 135.223 us 2M 303.906 us 5.385 us 12M 1786.557 us 21.250 us 16M 2391.890 us 27.437 us 24M 3570.895 us 39.937 us 32M 4755.234 us 51.797 us This is further reduced once the map/unmap_pages() support gets in which will result in just 1 TLBIASID as compared to 16 TLBIASIDs. Real world data also shows big difference in unmap performance as below: There were reports of camera frame drops because of high overhead in iommu unmap without this optimization because of frequent unmaps issued by camera of about 100MB/s taking more than 100ms thereby causing frame drops. Changes in v2: * Add a quirk to choose tlb_flush_all in partial walk flush * Set the quirk for QTI SoC implementation Sai Prakash Ranjan (3): iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list iommu/arm-smmu-qcom: Set IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC impl drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 11 +++++++++++ drivers/iommu/io-pgtable-arm.c | 3 ++- include/linux/io-pgtable.h | 11 +++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-18 2:51 ` Sai Prakash Ranjan @ 2021-06-18 2:51 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm, Bjorn Andersson, Douglas Anderson, Krishna Reddy, Thierry Reding, Tomasz Figa, Sai Prakash Ranjan Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context with tlb_flush_all() callback in partial walk flush to improve unmap performance on select few platforms where the cost of over-invalidation is less than the unmap latency. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- drivers/iommu/io-pgtable-arm.c | 3 ++- include/linux/io-pgtable.h | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 87def58e79b5..5d362f2214bd 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie) if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NON_STRICT | IO_PGTABLE_QUIRK_ARM_TTBR1 | - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | + IO_PGTABLE_QUIRK_TLB_INV_ALL)) return NULL; data = arm_lpae_alloc_pgtable(cfg); diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h index 4d40dfa75b55..45441592a0e6 100644 --- a/include/linux/io-pgtable.h +++ b/include/linux/io-pgtable.h @@ -82,6 +82,10 @@ struct io_pgtable_cfg { * * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability * attributes set in the TCR for a non-coherent page-table walker. + * + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate + * entire context for partial walk flush to increase unmap + * performance on select few platforms. */ #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) @@ -89,6 +93,7 @@ struct io_pgtable_cfg { #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) unsigned long quirks; unsigned long pgsize_bitmap; unsigned int ias; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-18 2:51 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context with tlb_flush_all() callback in partial walk flush to improve unmap performance on select few platforms where the cost of over-invalidation is less than the unmap latency. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- drivers/iommu/io-pgtable-arm.c | 3 ++- include/linux/io-pgtable.h | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 87def58e79b5..5d362f2214bd 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie) if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NON_STRICT | IO_PGTABLE_QUIRK_ARM_TTBR1 | - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | + IO_PGTABLE_QUIRK_TLB_INV_ALL)) return NULL; data = arm_lpae_alloc_pgtable(cfg); diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h index 4d40dfa75b55..45441592a0e6 100644 --- a/include/linux/io-pgtable.h +++ b/include/linux/io-pgtable.h @@ -82,6 +82,10 @@ struct io_pgtable_cfg { * * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability * attributes set in the TCR for a non-coherent page-table walker. + * + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate + * entire context for partial walk flush to increase unmap + * performance on select few platforms. */ #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) @@ -89,6 +93,7 @@ struct io_pgtable_cfg { #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) unsigned long quirks; unsigned long pgsize_bitmap; unsigned int ias; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-18 2:51 ` Sai Prakash Ranjan (?) @ 2021-06-21 15:45 ` Robin Murphy -1 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 15:45 UTC (permalink / raw) To: Sai Prakash Ranjan, Will Deacon, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-18 03:51, Sai Prakash Ranjan wrote: > Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context > with tlb_flush_all() callback in partial walk flush to improve unmap > performance on select few platforms where the cost of over-invalidation > is less than the unmap latency. I still think this doesn't belong anywhere near io-pgtable at all. It's a driver-internal decision how exactly it implements a non-leaf invalidation, and that may be more complex than a predetermined boolean decision. For example, I've just realised for SMMUv3 we can't invalidate multiple levels of table at once with a range command, since if we assume the whole thing is mapped at worst-case page granularity we may fail to invalidate any parts which are mapped as intermediate-level blocks. If invalidating a 1GB region (with 4KB granule) means having to fall back to 256K non-range commands, we may not want to invalidate by VA then, even though doing so for a 2MB region is still optimal. It's also quite feasible that drivers might want to do this for leaf invalidations too - if you don't like issuing 512 commands to invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? - and at that point the logic really has to be in the driver anyway. Robin. > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> > --- > drivers/iommu/io-pgtable-arm.c | 3 ++- > include/linux/io-pgtable.h | 5 +++++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index 87def58e79b5..5d362f2214bd 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie) > if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | > IO_PGTABLE_QUIRK_NON_STRICT | > IO_PGTABLE_QUIRK_ARM_TTBR1 | > - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) > + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | > + IO_PGTABLE_QUIRK_TLB_INV_ALL)) > return NULL; > > data = arm_lpae_alloc_pgtable(cfg); > diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h > index 4d40dfa75b55..45441592a0e6 100644 > --- a/include/linux/io-pgtable.h > +++ b/include/linux/io-pgtable.h > @@ -82,6 +82,10 @@ struct io_pgtable_cfg { > * > * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability > * attributes set in the TCR for a non-coherent page-table walker. > + * > + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate > + * entire context for partial walk flush to increase unmap > + * performance on select few platforms. > */ > #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) > #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) > @@ -89,6 +93,7 @@ struct io_pgtable_cfg { > #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) > #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) > #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) > + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) > unsigned long quirks; > unsigned long pgsize_bitmap; > unsigned int ias; > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-21 15:45 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 15:45 UTC (permalink / raw) To: Sai Prakash Ranjan, Will Deacon, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-18 03:51, Sai Prakash Ranjan wrote: > Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context > with tlb_flush_all() callback in partial walk flush to improve unmap > performance on select few platforms where the cost of over-invalidation > is less than the unmap latency. I still think this doesn't belong anywhere near io-pgtable at all. It's a driver-internal decision how exactly it implements a non-leaf invalidation, and that may be more complex than a predetermined boolean decision. For example, I've just realised for SMMUv3 we can't invalidate multiple levels of table at once with a range command, since if we assume the whole thing is mapped at worst-case page granularity we may fail to invalidate any parts which are mapped as intermediate-level blocks. If invalidating a 1GB region (with 4KB granule) means having to fall back to 256K non-range commands, we may not want to invalidate by VA then, even though doing so for a 2MB region is still optimal. It's also quite feasible that drivers might want to do this for leaf invalidations too - if you don't like issuing 512 commands to invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? - and at that point the logic really has to be in the driver anyway. Robin. > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> > --- > drivers/iommu/io-pgtable-arm.c | 3 ++- > include/linux/io-pgtable.h | 5 +++++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index 87def58e79b5..5d362f2214bd 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie) > if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | > IO_PGTABLE_QUIRK_NON_STRICT | > IO_PGTABLE_QUIRK_ARM_TTBR1 | > - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) > + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | > + IO_PGTABLE_QUIRK_TLB_INV_ALL)) > return NULL; > > data = arm_lpae_alloc_pgtable(cfg); > diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h > index 4d40dfa75b55..45441592a0e6 100644 > --- a/include/linux/io-pgtable.h > +++ b/include/linux/io-pgtable.h > @@ -82,6 +82,10 @@ struct io_pgtable_cfg { > * > * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability > * attributes set in the TCR for a non-coherent page-table walker. > + * > + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate > + * entire context for partial walk flush to increase unmap > + * performance on select few platforms. > */ > #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) > #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) > @@ -89,6 +93,7 @@ struct io_pgtable_cfg { > #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) > #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) > #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) > + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) > unsigned long quirks; > unsigned long pgsize_bitmap; > unsigned int ias; > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-21 15:45 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 15:45 UTC (permalink / raw) To: Sai Prakash Ranjan, Will Deacon, Joerg Roedel Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, linux-arm-kernel On 2021-06-18 03:51, Sai Prakash Ranjan wrote: > Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context > with tlb_flush_all() callback in partial walk flush to improve unmap > performance on select few platforms where the cost of over-invalidation > is less than the unmap latency. I still think this doesn't belong anywhere near io-pgtable at all. It's a driver-internal decision how exactly it implements a non-leaf invalidation, and that may be more complex than a predetermined boolean decision. For example, I've just realised for SMMUv3 we can't invalidate multiple levels of table at once with a range command, since if we assume the whole thing is mapped at worst-case page granularity we may fail to invalidate any parts which are mapped as intermediate-level blocks. If invalidating a 1GB region (with 4KB granule) means having to fall back to 256K non-range commands, we may not want to invalidate by VA then, even though doing so for a 2MB region is still optimal. It's also quite feasible that drivers might want to do this for leaf invalidations too - if you don't like issuing 512 commands to invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? - and at that point the logic really has to be in the driver anyway. Robin. > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> > --- > drivers/iommu/io-pgtable-arm.c | 3 ++- > include/linux/io-pgtable.h | 5 +++++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index 87def58e79b5..5d362f2214bd 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie) > if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | > IO_PGTABLE_QUIRK_NON_STRICT | > IO_PGTABLE_QUIRK_ARM_TTBR1 | > - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) > + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | > + IO_PGTABLE_QUIRK_TLB_INV_ALL)) > return NULL; > > data = arm_lpae_alloc_pgtable(cfg); > diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h > index 4d40dfa75b55..45441592a0e6 100644 > --- a/include/linux/io-pgtable.h > +++ b/include/linux/io-pgtable.h > @@ -82,6 +82,10 @@ struct io_pgtable_cfg { > * > * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability > * attributes set in the TCR for a non-coherent page-table walker. > + * > + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate > + * entire context for partial walk flush to increase unmap > + * performance on select few platforms. > */ > #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) > #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) > @@ -89,6 +93,7 @@ struct io_pgtable_cfg { > #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) > #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) > #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) > + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) > unsigned long quirks; > unsigned long pgsize_bitmap; > unsigned int ias; > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-21 15:45 ` Robin Murphy @ 2021-06-22 7:11 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-22 7:11 UTC (permalink / raw) To: Robin Murphy Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Hi Robin, On 2021-06-21 21:15, Robin Murphy wrote: > On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >> with tlb_flush_all() callback in partial walk flush to improve unmap >> performance on select few platforms where the cost of >> over-invalidation >> is less than the unmap latency. > > I still think this doesn't belong anywhere near io-pgtable at all. > It's a driver-internal decision how exactly it implements a non-leaf > invalidation, and that may be more complex than a predetermined > boolean decision. For example, I've just realised for SMMUv3 we can't > invalidate multiple levels of table at once with a range command, > since if we assume the whole thing is mapped at worst-case page > granularity we may fail to invalidate any parts which are mapped as > intermediate-level blocks. If invalidating a 1GB region (with 4KB > granule) means having to fall back to 256K non-range commands, we may > not want to invalidate by VA then, even though doing so for a 2MB > region is still optimal. > > It's also quite feasible that drivers might want to do this for leaf > invalidations too - if you don't like issuing 512 commands to > invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? > - and at that point the logic really has to be in the driver anyway. > Ok I will move this to tlb_flush_walk() functions in the drivers. In the previous v1 thread, you suggested to make the choice in iommu_get_dma_strict() test, I assume you meant the test in iommu_dma_init_domain() with a flag or was it the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in init_domain? I am still a bit confused on where this flag would be? Should this be a part of struct iommu_domain? Thanks, Sai > >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >> --- >> drivers/iommu/io-pgtable-arm.c | 3 ++- >> include/linux/io-pgtable.h | 5 +++++ >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/io-pgtable-arm.c >> b/drivers/iommu/io-pgtable-arm.c >> index 87def58e79b5..5d362f2214bd 100644 >> --- a/drivers/iommu/io-pgtable-arm.c >> +++ b/drivers/iommu/io-pgtable-arm.c >> @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg >> *cfg, void *cookie) >> if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | >> IO_PGTABLE_QUIRK_NON_STRICT | >> IO_PGTABLE_QUIRK_ARM_TTBR1 | >> - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) >> + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | >> + IO_PGTABLE_QUIRK_TLB_INV_ALL)) >> return NULL; >> data = arm_lpae_alloc_pgtable(cfg); >> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h >> index 4d40dfa75b55..45441592a0e6 100644 >> --- a/include/linux/io-pgtable.h >> +++ b/include/linux/io-pgtable.h >> @@ -82,6 +82,10 @@ struct io_pgtable_cfg { >> * >> * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability >> * attributes set in the TCR for a non-coherent page-table walker. >> + * >> + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate >> + * entire context for partial walk flush to increase unmap >> + * performance on select few platforms. >> */ >> #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) >> #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) >> @@ -89,6 +93,7 @@ struct io_pgtable_cfg { >> #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) >> #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) >> #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) >> + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) >> unsigned long quirks; >> unsigned long pgsize_bitmap; >> unsigned int ias; >> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 7:11 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-22 7:11 UTC (permalink / raw) To: Robin Murphy Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, Will Deacon, linux-arm-kernel Hi Robin, On 2021-06-21 21:15, Robin Murphy wrote: > On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >> with tlb_flush_all() callback in partial walk flush to improve unmap >> performance on select few platforms where the cost of >> over-invalidation >> is less than the unmap latency. > > I still think this doesn't belong anywhere near io-pgtable at all. > It's a driver-internal decision how exactly it implements a non-leaf > invalidation, and that may be more complex than a predetermined > boolean decision. For example, I've just realised for SMMUv3 we can't > invalidate multiple levels of table at once with a range command, > since if we assume the whole thing is mapped at worst-case page > granularity we may fail to invalidate any parts which are mapped as > intermediate-level blocks. If invalidating a 1GB region (with 4KB > granule) means having to fall back to 256K non-range commands, we may > not want to invalidate by VA then, even though doing so for a 2MB > region is still optimal. > > It's also quite feasible that drivers might want to do this for leaf > invalidations too - if you don't like issuing 512 commands to > invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? > - and at that point the logic really has to be in the driver anyway. > Ok I will move this to tlb_flush_walk() functions in the drivers. In the previous v1 thread, you suggested to make the choice in iommu_get_dma_strict() test, I assume you meant the test in iommu_dma_init_domain() with a flag or was it the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in init_domain? I am still a bit confused on where this flag would be? Should this be a part of struct iommu_domain? Thanks, Sai > >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >> --- >> drivers/iommu/io-pgtable-arm.c | 3 ++- >> include/linux/io-pgtable.h | 5 +++++ >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/io-pgtable-arm.c >> b/drivers/iommu/io-pgtable-arm.c >> index 87def58e79b5..5d362f2214bd 100644 >> --- a/drivers/iommu/io-pgtable-arm.c >> +++ b/drivers/iommu/io-pgtable-arm.c >> @@ -768,7 +768,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg >> *cfg, void *cookie) >> if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | >> IO_PGTABLE_QUIRK_NON_STRICT | >> IO_PGTABLE_QUIRK_ARM_TTBR1 | >> - IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)) >> + IO_PGTABLE_QUIRK_ARM_OUTER_WBWA | >> + IO_PGTABLE_QUIRK_TLB_INV_ALL)) >> return NULL; >> data = arm_lpae_alloc_pgtable(cfg); >> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h >> index 4d40dfa75b55..45441592a0e6 100644 >> --- a/include/linux/io-pgtable.h >> +++ b/include/linux/io-pgtable.h >> @@ -82,6 +82,10 @@ struct io_pgtable_cfg { >> * >> * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability >> * attributes set in the TCR for a non-coherent page-table walker. >> + * >> + * IO_PGTABLE_QUIRK_TLB_INV_ALL: Use TLBIALL/TLBIASID to invalidate >> + * entire context for partial walk flush to increase unmap >> + * performance on select few platforms. >> */ >> #define IO_PGTABLE_QUIRK_ARM_NS BIT(0) >> #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1) >> @@ -89,6 +93,7 @@ struct io_pgtable_cfg { >> #define IO_PGTABLE_QUIRK_NON_STRICT BIT(4) >> #define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5) >> #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6) >> + #define IO_PGTABLE_QUIRK_TLB_INV_ALL BIT(7) >> unsigned long quirks; >> unsigned long pgsize_bitmap; >> unsigned int ias; >> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-22 7:11 ` Sai Prakash Ranjan (?) @ 2021-06-22 12:11 ` Robin Murphy -1 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 12:11 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-22 08:11, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-21 21:15, Robin Murphy wrote: >> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>> with tlb_flush_all() callback in partial walk flush to improve unmap >>> performance on select few platforms where the cost of over-invalidation >>> is less than the unmap latency. >> >> I still think this doesn't belong anywhere near io-pgtable at all. >> It's a driver-internal decision how exactly it implements a non-leaf >> invalidation, and that may be more complex than a predetermined >> boolean decision. For example, I've just realised for SMMUv3 we can't >> invalidate multiple levels of table at once with a range command, >> since if we assume the whole thing is mapped at worst-case page >> granularity we may fail to invalidate any parts which are mapped as >> intermediate-level blocks. If invalidating a 1GB region (with 4KB >> granule) means having to fall back to 256K non-range commands, we may >> not want to invalidate by VA then, even though doing so for a 2MB >> region is still optimal. >> >> It's also quite feasible that drivers might want to do this for leaf >> invalidations too - if you don't like issuing 512 commands to >> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >> - and at that point the logic really has to be in the driver anyway. >> > > Ok I will move this to tlb_flush_walk() functions in the drivers. In the > previous > v1 thread, you suggested to make the choice in iommu_get_dma_strict() test, > I assume you meant the test in iommu_dma_init_domain() with a flag or > was it > the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in > init_domain? Yes, I meant literally inside the same condition where we currently set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in arm_smmu_init_domain_context(). > I am still a bit confused on where this flag would be? Should this be a > part > of struct iommu_domain? Well, if you were to rewrite the config with an alternative set of flush_ops at that point it would be implicit. For a flag, probably either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less useful than generalising straight to a "maximum number of by-VA invalidations it's worth sending individually" threshold value? It's clear to me what overall shape and separation of responsibility is most logical, but beyond that I don't have a particularly strong opinion on the exact implementation; I've just been chucking ideas around :) Cheers, Robin. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 12:11 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 12:11 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-22 08:11, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-21 21:15, Robin Murphy wrote: >> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>> with tlb_flush_all() callback in partial walk flush to improve unmap >>> performance on select few platforms where the cost of over-invalidation >>> is less than the unmap latency. >> >> I still think this doesn't belong anywhere near io-pgtable at all. >> It's a driver-internal decision how exactly it implements a non-leaf >> invalidation, and that may be more complex than a predetermined >> boolean decision. For example, I've just realised for SMMUv3 we can't >> invalidate multiple levels of table at once with a range command, >> since if we assume the whole thing is mapped at worst-case page >> granularity we may fail to invalidate any parts which are mapped as >> intermediate-level blocks. If invalidating a 1GB region (with 4KB >> granule) means having to fall back to 256K non-range commands, we may >> not want to invalidate by VA then, even though doing so for a 2MB >> region is still optimal. >> >> It's also quite feasible that drivers might want to do this for leaf >> invalidations too - if you don't like issuing 512 commands to >> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >> - and at that point the logic really has to be in the driver anyway. >> > > Ok I will move this to tlb_flush_walk() functions in the drivers. In the > previous > v1 thread, you suggested to make the choice in iommu_get_dma_strict() test, > I assume you meant the test in iommu_dma_init_domain() with a flag or > was it > the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in > init_domain? Yes, I meant literally inside the same condition where we currently set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in arm_smmu_init_domain_context(). > I am still a bit confused on where this flag would be? Should this be a > part > of struct iommu_domain? Well, if you were to rewrite the config with an alternative set of flush_ops at that point it would be implicit. For a flag, probably either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less useful than generalising straight to a "maximum number of by-VA invalidations it's worth sending individually" threshold value? It's clear to me what overall shape and separation of responsibility is most logical, but beyond that I don't have a particularly strong opinion on the exact implementation; I've just been chucking ideas around :) Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 12:11 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 12:11 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, Will Deacon, linux-arm-kernel On 2021-06-22 08:11, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-21 21:15, Robin Murphy wrote: >> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>> with tlb_flush_all() callback in partial walk flush to improve unmap >>> performance on select few platforms where the cost of over-invalidation >>> is less than the unmap latency. >> >> I still think this doesn't belong anywhere near io-pgtable at all. >> It's a driver-internal decision how exactly it implements a non-leaf >> invalidation, and that may be more complex than a predetermined >> boolean decision. For example, I've just realised for SMMUv3 we can't >> invalidate multiple levels of table at once with a range command, >> since if we assume the whole thing is mapped at worst-case page >> granularity we may fail to invalidate any parts which are mapped as >> intermediate-level blocks. If invalidating a 1GB region (with 4KB >> granule) means having to fall back to 256K non-range commands, we may >> not want to invalidate by VA then, even though doing so for a 2MB >> region is still optimal. >> >> It's also quite feasible that drivers might want to do this for leaf >> invalidations too - if you don't like issuing 512 commands to >> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >> - and at that point the logic really has to be in the driver anyway. >> > > Ok I will move this to tlb_flush_walk() functions in the drivers. In the > previous > v1 thread, you suggested to make the choice in iommu_get_dma_strict() test, > I assume you meant the test in iommu_dma_init_domain() with a flag or > was it > the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in > init_domain? Yes, I meant literally inside the same condition where we currently set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in arm_smmu_init_domain_context(). > I am still a bit confused on where this flag would be? Should this be a > part > of struct iommu_domain? Well, if you were to rewrite the config with an alternative set of flush_ops at that point it would be implicit. For a flag, probably either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less useful than generalising straight to a "maximum number of by-VA invalidations it's worth sending individually" threshold value? It's clear to me what overall shape and separation of responsibility is most logical, but beyond that I don't have a particularly strong opinion on the exact implementation; I've just been chucking ideas around :) Cheers, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-22 12:11 ` Robin Murphy @ 2021-06-22 14:27 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-22 14:27 UTC (permalink / raw) To: Robin Murphy Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Hi Robin, On 2021-06-22 17:41, Robin Murphy wrote: > On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >> Hi Robin, >> >> On 2021-06-21 21:15, Robin Murphy wrote: >>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire >>>> context >>>> with tlb_flush_all() callback in partial walk flush to improve unmap >>>> performance on select few platforms where the cost of >>>> over-invalidation >>>> is less than the unmap latency. >>> >>> I still think this doesn't belong anywhere near io-pgtable at all. >>> It's a driver-internal decision how exactly it implements a non-leaf >>> invalidation, and that may be more complex than a predetermined >>> boolean decision. For example, I've just realised for SMMUv3 we can't >>> invalidate multiple levels of table at once with a range command, >>> since if we assume the whole thing is mapped at worst-case page >>> granularity we may fail to invalidate any parts which are mapped as >>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>> granule) means having to fall back to 256K non-range commands, we may >>> not want to invalidate by VA then, even though doing so for a 2MB >>> region is still optimal. >>> >>> It's also quite feasible that drivers might want to do this for leaf >>> invalidations too - if you don't like issuing 512 commands to >>> invalidate 2MB, do you like issuing 511 commands to invalidate >>> 2044KB? >>> - and at that point the logic really has to be in the driver anyway. >>> >> >> Ok I will move this to tlb_flush_walk() functions in the drivers. In >> the previous >> v1 thread, you suggested to make the choice in iommu_get_dma_strict() >> test, >> I assume you meant the test in iommu_dma_init_domain() with a flag or >> was it >> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >> init_domain? > > Yes, I meant literally inside the same condition where we currently > set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in > arm_smmu_init_domain_context(). > Ok got it, thanks. >> I am still a bit confused on where this flag would be? Should this be >> a part >> of struct iommu_domain? > > Well, if you were to rewrite the config with an alternative set of > flush_ops at that point it would be implicit. For a flag, probably > either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less > useful than generalising straight to a "maximum number of by-VA > invalidations it's worth sending individually" threshold value? But then we would still need some flag to make this implementation specific (qcom specific for now) and this threshold would just be another condition although it would have been useful if this was generic enough. > It's clear to me what overall shape and separation of responsibility is > most logical, but beyond that I don't have a particularly strong > opinion on the exact implementation; I've just been chucking ideas > around :) > Your ideas are very informative and useful :) Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 14:27 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-22 14:27 UTC (permalink / raw) To: Robin Murphy Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, Will Deacon, linux-arm-kernel Hi Robin, On 2021-06-22 17:41, Robin Murphy wrote: > On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >> Hi Robin, >> >> On 2021-06-21 21:15, Robin Murphy wrote: >>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire >>>> context >>>> with tlb_flush_all() callback in partial walk flush to improve unmap >>>> performance on select few platforms where the cost of >>>> over-invalidation >>>> is less than the unmap latency. >>> >>> I still think this doesn't belong anywhere near io-pgtable at all. >>> It's a driver-internal decision how exactly it implements a non-leaf >>> invalidation, and that may be more complex than a predetermined >>> boolean decision. For example, I've just realised for SMMUv3 we can't >>> invalidate multiple levels of table at once with a range command, >>> since if we assume the whole thing is mapped at worst-case page >>> granularity we may fail to invalidate any parts which are mapped as >>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>> granule) means having to fall back to 256K non-range commands, we may >>> not want to invalidate by VA then, even though doing so for a 2MB >>> region is still optimal. >>> >>> It's also quite feasible that drivers might want to do this for leaf >>> invalidations too - if you don't like issuing 512 commands to >>> invalidate 2MB, do you like issuing 511 commands to invalidate >>> 2044KB? >>> - and at that point the logic really has to be in the driver anyway. >>> >> >> Ok I will move this to tlb_flush_walk() functions in the drivers. In >> the previous >> v1 thread, you suggested to make the choice in iommu_get_dma_strict() >> test, >> I assume you meant the test in iommu_dma_init_domain() with a flag or >> was it >> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >> init_domain? > > Yes, I meant literally inside the same condition where we currently > set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in > arm_smmu_init_domain_context(). > Ok got it, thanks. >> I am still a bit confused on where this flag would be? Should this be >> a part >> of struct iommu_domain? > > Well, if you were to rewrite the config with an alternative set of > flush_ops at that point it would be implicit. For a flag, probably > either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less > useful than generalising straight to a "maximum number of by-VA > invalidations it's worth sending individually" threshold value? But then we would still need some flag to make this implementation specific (qcom specific for now) and this threshold would just be another condition although it would have been useful if this was generic enough. > It's clear to me what overall shape and separation of responsibility is > most logical, but beyond that I don't have a particularly strong > opinion on the exact implementation; I've just been chucking ideas > around :) > Your ideas are very informative and useful :) Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-22 14:27 ` Sai Prakash Ranjan (?) @ 2021-06-22 18:37 ` Robin Murphy -1 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 18:37 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-22 15:27, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-22 17:41, Robin Murphy wrote: >> On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >>> Hi Robin, >>> >>> On 2021-06-21 21:15, Robin Murphy wrote: >>>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>>>> with tlb_flush_all() callback in partial walk flush to improve unmap >>>>> performance on select few platforms where the cost of >>>>> over-invalidation >>>>> is less than the unmap latency. >>>> >>>> I still think this doesn't belong anywhere near io-pgtable at all. >>>> It's a driver-internal decision how exactly it implements a non-leaf >>>> invalidation, and that may be more complex than a predetermined >>>> boolean decision. For example, I've just realised for SMMUv3 we can't >>>> invalidate multiple levels of table at once with a range command, >>>> since if we assume the whole thing is mapped at worst-case page >>>> granularity we may fail to invalidate any parts which are mapped as >>>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>>> granule) means having to fall back to 256K non-range commands, we may >>>> not want to invalidate by VA then, even though doing so for a 2MB >>>> region is still optimal. >>>> >>>> It's also quite feasible that drivers might want to do this for leaf >>>> invalidations too - if you don't like issuing 512 commands to >>>> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >>>> - and at that point the logic really has to be in the driver anyway. >>>> >>> >>> Ok I will move this to tlb_flush_walk() functions in the drivers. In >>> the previous >>> v1 thread, you suggested to make the choice in iommu_get_dma_strict() >>> test, >>> I assume you meant the test in iommu_dma_init_domain() with a flag or >>> was it >>> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >>> init_domain? >> >> Yes, I meant literally inside the same condition where we currently >> set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in >> arm_smmu_init_domain_context(). >> > > Ok got it, thanks. > >>> I am still a bit confused on where this flag would be? Should this be >>> a part >>> of struct iommu_domain? >> >> Well, if you were to rewrite the config with an alternative set of >> flush_ops at that point it would be implicit. For a flag, probably >> either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less >> useful than generalising straight to a "maximum number of by-VA >> invalidations it's worth sending individually" threshold value? > > But then we would still need some flag to make this implementation > specific (qcom specific for now) and this threshold would just be > another condition although it would have been useful if this was > generic enough. Well, for that approach I assume we could do something like special-case 0, or if it's a mutable per-domain value maybe just initialise it to SIZE_MAX or whatever such that it would never be reached in practice. Whichever way, it was meant to be implied that anything at the domain level would still be subject to final adjustment by the init_context hook. Robin. >> It's clear to me what overall shape and separation of responsibility is >> most logical, but beyond that I don't have a particularly strong >> opinion on the exact implementation; I've just been chucking ideas >> around :) >> > > Your ideas are very informative and useful :) > > Thanks, > Sai > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 18:37 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 18:37 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel On 2021-06-22 15:27, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-22 17:41, Robin Murphy wrote: >> On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >>> Hi Robin, >>> >>> On 2021-06-21 21:15, Robin Murphy wrote: >>>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>>>> with tlb_flush_all() callback in partial walk flush to improve unmap >>>>> performance on select few platforms where the cost of >>>>> over-invalidation >>>>> is less than the unmap latency. >>>> >>>> I still think this doesn't belong anywhere near io-pgtable at all. >>>> It's a driver-internal decision how exactly it implements a non-leaf >>>> invalidation, and that may be more complex than a predetermined >>>> boolean decision. For example, I've just realised for SMMUv3 we can't >>>> invalidate multiple levels of table at once with a range command, >>>> since if we assume the whole thing is mapped at worst-case page >>>> granularity we may fail to invalidate any parts which are mapped as >>>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>>> granule) means having to fall back to 256K non-range commands, we may >>>> not want to invalidate by VA then, even though doing so for a 2MB >>>> region is still optimal. >>>> >>>> It's also quite feasible that drivers might want to do this for leaf >>>> invalidations too - if you don't like issuing 512 commands to >>>> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >>>> - and at that point the logic really has to be in the driver anyway. >>>> >>> >>> Ok I will move this to tlb_flush_walk() functions in the drivers. In >>> the previous >>> v1 thread, you suggested to make the choice in iommu_get_dma_strict() >>> test, >>> I assume you meant the test in iommu_dma_init_domain() with a flag or >>> was it >>> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >>> init_domain? >> >> Yes, I meant literally inside the same condition where we currently >> set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in >> arm_smmu_init_domain_context(). >> > > Ok got it, thanks. > >>> I am still a bit confused on where this flag would be? Should this be >>> a part >>> of struct iommu_domain? >> >> Well, if you were to rewrite the config with an alternative set of >> flush_ops at that point it would be implicit. For a flag, probably >> either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less >> useful than generalising straight to a "maximum number of by-VA >> invalidations it's worth sending individually" threshold value? > > But then we would still need some flag to make this implementation > specific (qcom specific for now) and this threshold would just be > another condition although it would have been useful if this was > generic enough. Well, for that approach I assume we could do something like special-case 0, or if it's a mutable per-domain value maybe just initialise it to SIZE_MAX or whatever such that it would never be reached in practice. Whichever way, it was meant to be implied that anything at the domain level would still be subject to final adjustment by the init_context hook. Robin. >> It's clear to me what overall shape and separation of responsibility is >> most logical, but beyond that I don't have a particularly strong >> opinion on the exact implementation; I've just been chucking ideas >> around :) >> > > Your ideas are very informative and useful :) > > Thanks, > Sai > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-22 18:37 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-22 18:37 UTC (permalink / raw) To: Sai Prakash Ranjan Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, Will Deacon, linux-arm-kernel On 2021-06-22 15:27, Sai Prakash Ranjan wrote: > Hi Robin, > > On 2021-06-22 17:41, Robin Murphy wrote: >> On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >>> Hi Robin, >>> >>> On 2021-06-21 21:15, Robin Murphy wrote: >>>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire context >>>>> with tlb_flush_all() callback in partial walk flush to improve unmap >>>>> performance on select few platforms where the cost of >>>>> over-invalidation >>>>> is less than the unmap latency. >>>> >>>> I still think this doesn't belong anywhere near io-pgtable at all. >>>> It's a driver-internal decision how exactly it implements a non-leaf >>>> invalidation, and that may be more complex than a predetermined >>>> boolean decision. For example, I've just realised for SMMUv3 we can't >>>> invalidate multiple levels of table at once with a range command, >>>> since if we assume the whole thing is mapped at worst-case page >>>> granularity we may fail to invalidate any parts which are mapped as >>>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>>> granule) means having to fall back to 256K non-range commands, we may >>>> not want to invalidate by VA then, even though doing so for a 2MB >>>> region is still optimal. >>>> >>>> It's also quite feasible that drivers might want to do this for leaf >>>> invalidations too - if you don't like issuing 512 commands to >>>> invalidate 2MB, do you like issuing 511 commands to invalidate 2044KB? >>>> - and at that point the logic really has to be in the driver anyway. >>>> >>> >>> Ok I will move this to tlb_flush_walk() functions in the drivers. In >>> the previous >>> v1 thread, you suggested to make the choice in iommu_get_dma_strict() >>> test, >>> I assume you meant the test in iommu_dma_init_domain() with a flag or >>> was it >>> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >>> init_domain? >> >> Yes, I meant literally inside the same condition where we currently >> set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in >> arm_smmu_init_domain_context(). >> > > Ok got it, thanks. > >>> I am still a bit confused on where this flag would be? Should this be >>> a part >>> of struct iommu_domain? >> >> Well, if you were to rewrite the config with an alternative set of >> flush_ops at that point it would be implicit. For a flag, probably >> either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be less >> useful than generalising straight to a "maximum number of by-VA >> invalidations it's worth sending individually" threshold value? > > But then we would still need some flag to make this implementation > specific (qcom specific for now) and this threshold would just be > another condition although it would have been useful if this was > generic enough. Well, for that approach I assume we could do something like special-case 0, or if it's a mutable per-domain value maybe just initialise it to SIZE_MAX or whatever such that it would never be reached in practice. Whichever way, it was meant to be implied that anything at the domain level would still be subject to final adjustment by the init_context hook. Robin. >> It's clear to me what overall shape and separation of responsibility is >> most logical, but beyond that I don't have a particularly strong >> opinion on the exact implementation; I've just been chucking ideas >> around :) >> > > Your ideas are very informative and useful :) > > Thanks, > Sai > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush 2021-06-22 18:37 ` Robin Murphy @ 2021-06-23 13:43 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-23 13:43 UTC (permalink / raw) To: Robin Murphy Cc: Will Deacon, Joerg Roedel, Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Hi Robin, On 2021-06-23 00:07, Robin Murphy wrote: > On 2021-06-22 15:27, Sai Prakash Ranjan wrote: >> Hi Robin, >> >> On 2021-06-22 17:41, Robin Murphy wrote: >>> On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >>>> Hi Robin, >>>> >>>> On 2021-06-21 21:15, Robin Murphy wrote: >>>>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire >>>>>> context >>>>>> with tlb_flush_all() callback in partial walk flush to improve >>>>>> unmap >>>>>> performance on select few platforms where the cost of >>>>>> over-invalidation >>>>>> is less than the unmap latency. >>>>> >>>>> I still think this doesn't belong anywhere near io-pgtable at all. >>>>> It's a driver-internal decision how exactly it implements a >>>>> non-leaf >>>>> invalidation, and that may be more complex than a predetermined >>>>> boolean decision. For example, I've just realised for SMMUv3 we >>>>> can't >>>>> invalidate multiple levels of table at once with a range command, >>>>> since if we assume the whole thing is mapped at worst-case page >>>>> granularity we may fail to invalidate any parts which are mapped as >>>>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>>>> granule) means having to fall back to 256K non-range commands, we >>>>> may >>>>> not want to invalidate by VA then, even though doing so for a 2MB >>>>> region is still optimal. >>>>> >>>>> It's also quite feasible that drivers might want to do this for >>>>> leaf >>>>> invalidations too - if you don't like issuing 512 commands to >>>>> invalidate 2MB, do you like issuing 511 commands to invalidate >>>>> 2044KB? >>>>> - and at that point the logic really has to be in the driver >>>>> anyway. >>>>> >>>> >>>> Ok I will move this to tlb_flush_walk() functions in the drivers. In >>>> the previous >>>> v1 thread, you suggested to make the choice in >>>> iommu_get_dma_strict() test, >>>> I assume you meant the test in iommu_dma_init_domain() with a flag >>>> or was it >>>> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >>>> init_domain? >>> >>> Yes, I meant literally inside the same condition where we currently >>> set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in >>> arm_smmu_init_domain_context(). >>> >> >> Ok got it, thanks. >> >>>> I am still a bit confused on where this flag would be? Should this >>>> be a part >>>> of struct iommu_domain? >>> >>> Well, if you were to rewrite the config with an alternative set of >>> flush_ops at that point it would be implicit. For a flag, probably >>> either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be >>> less >>> useful than generalising straight to a "maximum number of by-VA >>> invalidations it's worth sending individually" threshold value? >> >> But then we would still need some flag to make this implementation >> specific (qcom specific for now) and this threshold would just be >> another condition although it would have been useful if this was >> generic enough. > > Well, for that approach I assume we could do something like > special-case 0, or if it's a mutable per-domain value maybe just > initialise it to SIZE_MAX or whatever such that it would never be > reached in practice. Whichever way, it was meant to be implied that > anything at the domain level would still be subject to final > adjustment by the init_context hook. > Ok that should work, so I went ahead with another set of flush_ops and posted out v3. Thanks, Sai > >>> It's clear to me what overall shape and separation of responsibility >>> is >>> most logical, but beyond that I don't have a particularly strong >>> opinion on the exact implementation; I've just been chucking ideas >>> around :) >>> >> >> Your ideas are very informative and useful :) >> >> Thanks, >> Sai >> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush @ 2021-06-23 13:43 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-23 13:43 UTC (permalink / raw) To: Robin Murphy Cc: linux-arm-msm, Douglas Anderson, linux-kernel, iommu, Thierry Reding, Will Deacon, linux-arm-kernel Hi Robin, On 2021-06-23 00:07, Robin Murphy wrote: > On 2021-06-22 15:27, Sai Prakash Ranjan wrote: >> Hi Robin, >> >> On 2021-06-22 17:41, Robin Murphy wrote: >>> On 2021-06-22 08:11, Sai Prakash Ranjan wrote: >>>> Hi Robin, >>>> >>>> On 2021-06-21 21:15, Robin Murphy wrote: >>>>> On 2021-06-18 03:51, Sai Prakash Ranjan wrote: >>>>>> Add a quirk IO_PGTABLE_QUIRK_TLB_INV_ALL to invalidate entire >>>>>> context >>>>>> with tlb_flush_all() callback in partial walk flush to improve >>>>>> unmap >>>>>> performance on select few platforms where the cost of >>>>>> over-invalidation >>>>>> is less than the unmap latency. >>>>> >>>>> I still think this doesn't belong anywhere near io-pgtable at all. >>>>> It's a driver-internal decision how exactly it implements a >>>>> non-leaf >>>>> invalidation, and that may be more complex than a predetermined >>>>> boolean decision. For example, I've just realised for SMMUv3 we >>>>> can't >>>>> invalidate multiple levels of table at once with a range command, >>>>> since if we assume the whole thing is mapped at worst-case page >>>>> granularity we may fail to invalidate any parts which are mapped as >>>>> intermediate-level blocks. If invalidating a 1GB region (with 4KB >>>>> granule) means having to fall back to 256K non-range commands, we >>>>> may >>>>> not want to invalidate by VA then, even though doing so for a 2MB >>>>> region is still optimal. >>>>> >>>>> It's also quite feasible that drivers might want to do this for >>>>> leaf >>>>> invalidations too - if you don't like issuing 512 commands to >>>>> invalidate 2MB, do you like issuing 511 commands to invalidate >>>>> 2044KB? >>>>> - and at that point the logic really has to be in the driver >>>>> anyway. >>>>> >>>> >>>> Ok I will move this to tlb_flush_walk() functions in the drivers. In >>>> the previous >>>> v1 thread, you suggested to make the choice in >>>> iommu_get_dma_strict() test, >>>> I assume you meant the test in iommu_dma_init_domain() with a flag >>>> or was it >>>> the leaf driver(ex:arm-smmu.c) test of iommu_get_dma_strict() in >>>> init_domain? >>> >>> Yes, I meant literally inside the same condition where we currently >>> set "pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;" in >>> arm_smmu_init_domain_context(). >>> >> >> Ok got it, thanks. >> >>>> I am still a bit confused on where this flag would be? Should this >>>> be a part >>>> of struct iommu_domain? >>> >>> Well, if you were to rewrite the config with an alternative set of >>> flush_ops at that point it would be implicit. For a flag, probably >>> either in arm_smmu_domain or arm_smmu_impl. Maybe a flag would be >>> less >>> useful than generalising straight to a "maximum number of by-VA >>> invalidations it's worth sending individually" threshold value? >> >> But then we would still need some flag to make this implementation >> specific (qcom specific for now) and this threshold would just be >> another condition although it would have been useful if this was >> generic enough. > > Well, for that approach I assume we could do something like > special-case 0, or if it's a mutable per-domain value maybe just > initialise it to SIZE_MAX or whatever such that it would never be > reached in practice. Whichever way, it was meant to be implied that > anything at the domain level would still be subject to final > adjustment by the init_context hook. > Ok that should work, so I went ahead with another set of flush_ops and posted out v3. Thanks, Sai > >>> It's clear to me what overall shape and separation of responsibility >>> is >>> most logical, but beyond that I don't have a particularly strong >>> opinion on the exact implementation; I've just been chucking ideas >>> around :) >>> >> >> Your ideas are very informative and useful :) >> >> Thanks, >> Sai >> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list 2021-06-18 2:51 ` Sai Prakash Ranjan @ 2021-06-18 2:51 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm, Bjorn Andersson, Douglas Anderson, Krishna Reddy, Thierry Reding, Tomasz Figa, Sai Prakash Ranjan Currently for iommu_unmap() of large scatter-gather list with page size elements, the majority of time is spent in flushing of partial walks in __arm_lpae_unmap() which is a VA based TLB invalidation invalidating page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support range based invalidations like on arm-smmu-v3.2. For example: to unmap a 32MB scatter-gather list with page size elements (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge overhead. So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate the entire context for partial walk flush on select few platforms where cost of over-invalidation is less than unmap latency using the newly introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for non-strict mode given its all about over-invalidation saving time on individual unmaps and non-deterministic generally. For this example of 32MB scatter-gather list unmap, this results in just 16 ASID based TLB invalidations (TLBIASIDs) as opposed to 8192 TLBIVAs thereby increasing the performance of unmaps drastically. Test on QTI SM8150 SoC for 10 iterations of iommu_{map_sg}/unmap: (average over 10 iterations) Before this optimization: size iommu_map_sg iommu_unmap 4K 2.067 us 1.854 us 64K 9.598 us 8.802 us 1M 148.890 us 130.718 us 2M 305.864 us 67.291 us 12M 1793.604 us 390.838 us 16M 2386.848 us 518.187 us 24M 3563.296 us 775.989 us 32M 4747.171 us 1033.364 us After this optimization: size iommu_map_sg iommu_unmap 4K 1.723 us 1.765 us 64K 9.880 us 8.869 us 1M 155.364 us 135.223 us 2M 303.906 us 5.385 us 12M 1786.557 us 21.250 us 16M 2391.890 us 27.437 us 24M 3570.895 us 39.937 us 32M 4755.234 us 51.797 us This is further reduced once the map/unmap_pages() support gets in which will result in just 1 TLBIASID as compared to 16 TLBIASIDs. Real world data also shows big difference in unmap performance as below: There were reports of camera frame drops because of high overhead in iommu unmap without this optimization because of frequent unmaps issued by camera of about 100MB/s taking more than 100ms thereby causing frame drops. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- include/linux/io-pgtable.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h index 45441592a0e6..fd6b30cfdbf7 100644 --- a/include/linux/io-pgtable.h +++ b/include/linux/io-pgtable.h @@ -219,6 +219,12 @@ static inline void io_pgtable_tlb_flush_walk(struct io_pgtable *iop, unsigned long iova, size_t size, size_t granule) { + if (iop->cfg.quirks & IO_PGTABLE_QUIRK_NON_STRICT || + iop->cfg.quirks & IO_PGTABLE_QUIRK_TLB_INV_ALL) { + iop->cfg.tlb->tlb_flush_all(iop->cookie); + return; + } + if (iop->cfg.tlb && iop->cfg.tlb->tlb_flush_walk) iop->cfg.tlb->tlb_flush_walk(iova, size, granule, iop->cookie); } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-18 2:51 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Currently for iommu_unmap() of large scatter-gather list with page size elements, the majority of time is spent in flushing of partial walks in __arm_lpae_unmap() which is a VA based TLB invalidation invalidating page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support range based invalidations like on arm-smmu-v3.2. For example: to unmap a 32MB scatter-gather list with page size elements (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge overhead. So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate the entire context for partial walk flush on select few platforms where cost of over-invalidation is less than unmap latency using the newly introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for non-strict mode given its all about over-invalidation saving time on individual unmaps and non-deterministic generally. For this example of 32MB scatter-gather list unmap, this results in just 16 ASID based TLB invalidations (TLBIASIDs) as opposed to 8192 TLBIVAs thereby increasing the performance of unmaps drastically. Test on QTI SM8150 SoC for 10 iterations of iommu_{map_sg}/unmap: (average over 10 iterations) Before this optimization: size iommu_map_sg iommu_unmap 4K 2.067 us 1.854 us 64K 9.598 us 8.802 us 1M 148.890 us 130.718 us 2M 305.864 us 67.291 us 12M 1793.604 us 390.838 us 16M 2386.848 us 518.187 us 24M 3563.296 us 775.989 us 32M 4747.171 us 1033.364 us After this optimization: size iommu_map_sg iommu_unmap 4K 1.723 us 1.765 us 64K 9.880 us 8.869 us 1M 155.364 us 135.223 us 2M 303.906 us 5.385 us 12M 1786.557 us 21.250 us 16M 2391.890 us 27.437 us 24M 3570.895 us 39.937 us 32M 4755.234 us 51.797 us This is further reduced once the map/unmap_pages() support gets in which will result in just 1 TLBIASID as compared to 16 TLBIASIDs. Real world data also shows big difference in unmap performance as below: There were reports of camera frame drops because of high overhead in iommu unmap without this optimization because of frequent unmaps issued by camera of about 100MB/s taking more than 100ms thereby causing frame drops. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- include/linux/io-pgtable.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h index 45441592a0e6..fd6b30cfdbf7 100644 --- a/include/linux/io-pgtable.h +++ b/include/linux/io-pgtable.h @@ -219,6 +219,12 @@ static inline void io_pgtable_tlb_flush_walk(struct io_pgtable *iop, unsigned long iova, size_t size, size_t granule) { + if (iop->cfg.quirks & IO_PGTABLE_QUIRK_NON_STRICT || + iop->cfg.quirks & IO_PGTABLE_QUIRK_TLB_INV_ALL) { + iop->cfg.tlb->tlb_flush_all(iop->cookie); + return; + } + if (iop->cfg.tlb && iop->cfg.tlb->tlb_flush_walk) iop->cfg.tlb->tlb_flush_walk(iova, size, granule, iop->cookie); } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list 2021-06-18 2:51 ` Sai Prakash Ranjan (?) @ 2021-06-18 22:09 ` Doug Anderson -1 siblings, 0 replies; 31+ messages in thread From: Doug Anderson @ 2021-06-18 22:09 UTC (permalink / raw) To: Sai Prakash Ranjan, Robin Murphy Cc: Will Deacon, Joerg Roedel, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,, Linux ARM, LKML, linux-arm-msm, Bjorn Andersson, Krishna Reddy, Thierry Reding, Tomasz Figa Hi, On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Currently for iommu_unmap() of large scatter-gather list with page size > elements, the majority of time is spent in flushing of partial walks in > __arm_lpae_unmap() which is a VA based TLB invalidation invalidating > page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support > range based invalidations like on arm-smmu-v3.2. > > For example: to unmap a 32MB scatter-gather list with page size elements > (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB > for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) > resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge > overhead. > > So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate > the entire context for partial walk flush on select few platforms where > cost of over-invalidation is less than unmap latency It would probably be worth punching this description up a little bit. Elsewhere you said in more detail why this over-invalidation is less of a big deal for the Qualcomm SMMU. It's probably worth saying something like that here, too. Like this bit paraphrased from your other email: On qcom impl, we have several performance improvements for TLB cache invalidations in HW like wait-for-safe (for realtime clients such as camera and display) and few others to allow for cache lookups/updates when TLBI is in progress for the same context bank. > using the newly > introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for > non-strict mode given its all about over-invalidation saving time on > individual unmaps and non-deterministic generally. As per usual I'm mostly clueless, but I don't quite understand why you want this new behavior for non-strict mode. To me it almost seems like the opposite? Specifically, non-strict mode is already outside the critical path today and so there's no need to optimize it. I'm probably not explaining myself clearly, but I guess i'm thinking: a) today for strict, unmap is in the critical path and it's important to get it out of there. Getting it out of the critical path is so important that we're willing to over-invalidate to speed up the critical path. b) today for non-strict, unmap is not in the critical path. So I would almost expect your patch to _disable_ your new feature for non-strict mappings, not auto-enable your new feature for non-strict mappings. If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin was the one that suggested the behavior you're implementing, so it's more likely he's right than I am. ;-) -Doug ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-18 22:09 ` Doug Anderson 0 siblings, 0 replies; 31+ messages in thread From: Doug Anderson @ 2021-06-18 22:09 UTC (permalink / raw) To: Sai Prakash Ranjan, Robin Murphy Cc: Tomasz Figa, linux-arm-msm, Joerg Roedel, LKML, Bjorn Andersson, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Thierry Reding, Will Deacon, Linux ARM Hi, On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Currently for iommu_unmap() of large scatter-gather list with page size > elements, the majority of time is spent in flushing of partial walks in > __arm_lpae_unmap() which is a VA based TLB invalidation invalidating > page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support > range based invalidations like on arm-smmu-v3.2. > > For example: to unmap a 32MB scatter-gather list with page size elements > (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB > for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) > resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge > overhead. > > So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate > the entire context for partial walk flush on select few platforms where > cost of over-invalidation is less than unmap latency It would probably be worth punching this description up a little bit. Elsewhere you said in more detail why this over-invalidation is less of a big deal for the Qualcomm SMMU. It's probably worth saying something like that here, too. Like this bit paraphrased from your other email: On qcom impl, we have several performance improvements for TLB cache invalidations in HW like wait-for-safe (for realtime clients such as camera and display) and few others to allow for cache lookups/updates when TLBI is in progress for the same context bank. > using the newly > introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for > non-strict mode given its all about over-invalidation saving time on > individual unmaps and non-deterministic generally. As per usual I'm mostly clueless, but I don't quite understand why you want this new behavior for non-strict mode. To me it almost seems like the opposite? Specifically, non-strict mode is already outside the critical path today and so there's no need to optimize it. I'm probably not explaining myself clearly, but I guess i'm thinking: a) today for strict, unmap is in the critical path and it's important to get it out of there. Getting it out of the critical path is so important that we're willing to over-invalidate to speed up the critical path. b) today for non-strict, unmap is not in the critical path. So I would almost expect your patch to _disable_ your new feature for non-strict mappings, not auto-enable your new feature for non-strict mappings. If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin was the one that suggested the behavior you're implementing, so it's more likely he's right than I am. ;-) -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-18 22:09 ` Doug Anderson 0 siblings, 0 replies; 31+ messages in thread From: Doug Anderson @ 2021-06-18 22:09 UTC (permalink / raw) To: Sai Prakash Ranjan, Robin Murphy Cc: linux-arm-msm, LKML, list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, , Thierry Reding, Will Deacon, Linux ARM Hi, On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Currently for iommu_unmap() of large scatter-gather list with page size > elements, the majority of time is spent in flushing of partial walks in > __arm_lpae_unmap() which is a VA based TLB invalidation invalidating > page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support > range based invalidations like on arm-smmu-v3.2. > > For example: to unmap a 32MB scatter-gather list with page size elements > (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB > for 4K granule) and each of 2MB will further result in 512 TLBIVAs (2MB/4K) > resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge > overhead. > > So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate > the entire context for partial walk flush on select few platforms where > cost of over-invalidation is less than unmap latency It would probably be worth punching this description up a little bit. Elsewhere you said in more detail why this over-invalidation is less of a big deal for the Qualcomm SMMU. It's probably worth saying something like that here, too. Like this bit paraphrased from your other email: On qcom impl, we have several performance improvements for TLB cache invalidations in HW like wait-for-safe (for realtime clients such as camera and display) and few others to allow for cache lookups/updates when TLBI is in progress for the same context bank. > using the newly > introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for > non-strict mode given its all about over-invalidation saving time on > individual unmaps and non-deterministic generally. As per usual I'm mostly clueless, but I don't quite understand why you want this new behavior for non-strict mode. To me it almost seems like the opposite? Specifically, non-strict mode is already outside the critical path today and so there's no need to optimize it. I'm probably not explaining myself clearly, but I guess i'm thinking: a) today for strict, unmap is in the critical path and it's important to get it out of there. Getting it out of the critical path is so important that we're willing to over-invalidate to speed up the critical path. b) today for non-strict, unmap is not in the critical path. So I would almost expect your patch to _disable_ your new feature for non-strict mappings, not auto-enable your new feature for non-strict mappings. If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin was the one that suggested the behavior you're implementing, so it's more likely he's right than I am. ;-) -Doug _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list 2021-06-18 22:09 ` Doug Anderson @ 2021-06-21 5:47 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-21 5:47 UTC (permalink / raw) To: Doug Anderson Cc: Robin Murphy, Will Deacon, Joerg Roedel, list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>,, Linux ARM, LKML, linux-arm-msm, Bjorn Andersson, Krishna Reddy, Thierry Reding, Tomasz Figa Hi, On 2021-06-19 03:39, Doug Anderson wrote: > Hi, > > On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> Currently for iommu_unmap() of large scatter-gather list with page >> size >> elements, the majority of time is spent in flushing of partial walks >> in >> __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >> page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support >> range based invalidations like on arm-smmu-v3.2. >> >> For example: to unmap a 32MB scatter-gather list with page size >> elements >> (8192 entries), there are 16->2MB buffer unmaps based on the pgsize >> (2MB >> for 4K granule) and each of 2MB will further result in 512 TLBIVAs >> (2MB/4K) >> resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a >> huge >> overhead. >> >> So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to >> invalidate >> the entire context for partial walk flush on select few platforms >> where >> cost of over-invalidation is less than unmap latency > > It would probably be worth punching this description up a little bit. > Elsewhere you said in more detail why this over-invalidation is less > of a big deal for the Qualcomm SMMU. It's probably worth saying > something like that here, too. Like this bit paraphrased from your > other email: > > On qcom impl, we have several performance improvements for TLB cache > invalidations in HW like wait-for-safe (for realtime clients such as > camera and display) and few others to allow for cache lookups/updates > when TLBI is in progress for the same context bank. > Sure will add this info as well in the next version. > >> using the newly >> introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for >> non-strict mode given its all about over-invalidation saving time on >> individual unmaps and non-deterministic generally. > > As per usual I'm mostly clueless, but I don't quite understand why you > want this new behavior for non-strict mode. To me it almost seems like > the opposite? Specifically, non-strict mode is already outside the > critical path today and so there's no need to optimize it. I'm > probably not explaining myself clearly, but I guess i'm thinking: > > a) today for strict, unmap is in the critical path and it's important > to get it out of there. Getting it out of the critical path is so > important that we're willing to over-invalidate to speed up the > critical path. > > b) today for non-strict, unmap is not in the critical path. > > So I would almost expect your patch to _disable_ your new feature for > non-strict mappings, not auto-enable your new feature for non-strict > mappings. > > If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin > was the one that suggested the behavior you're implementing, so it's > more likely he's right than I am. ;-) > Thanks for taking a look. Non-strict mode is only for leaf entries and dma domains and this optimization is for non-leaf entries and is applicable for both, see __arm_lpae_unmap(). In other words, if you have iommu.strict=0 (non-strict mode) and try unmapping a large sg buffer as the problem described in the commit text, you would still go via this path in unmap and see the delay without this patch. So what Robin suggested is that, let's do this unconditionally for all users with non-strict mode as opposed to only restricting it to implementation specific in case of strict mode. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-21 5:47 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-21 5:47 UTC (permalink / raw) To: Doug Anderson Cc: Robin Murphy, LKML, list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>, , linux-arm-msm, Thierry Reding, Will Deacon, Linux ARM Hi, On 2021-06-19 03:39, Doug Anderson wrote: > Hi, > > On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> Currently for iommu_unmap() of large scatter-gather list with page >> size >> elements, the majority of time is spent in flushing of partial walks >> in >> __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >> page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support >> range based invalidations like on arm-smmu-v3.2. >> >> For example: to unmap a 32MB scatter-gather list with page size >> elements >> (8192 entries), there are 16->2MB buffer unmaps based on the pgsize >> (2MB >> for 4K granule) and each of 2MB will further result in 512 TLBIVAs >> (2MB/4K) >> resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a >> huge >> overhead. >> >> So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to >> invalidate >> the entire context for partial walk flush on select few platforms >> where >> cost of over-invalidation is less than unmap latency > > It would probably be worth punching this description up a little bit. > Elsewhere you said in more detail why this over-invalidation is less > of a big deal for the Qualcomm SMMU. It's probably worth saying > something like that here, too. Like this bit paraphrased from your > other email: > > On qcom impl, we have several performance improvements for TLB cache > invalidations in HW like wait-for-safe (for realtime clients such as > camera and display) and few others to allow for cache lookups/updates > when TLBI is in progress for the same context bank. > Sure will add this info as well in the next version. > >> using the newly >> introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for >> non-strict mode given its all about over-invalidation saving time on >> individual unmaps and non-deterministic generally. > > As per usual I'm mostly clueless, but I don't quite understand why you > want this new behavior for non-strict mode. To me it almost seems like > the opposite? Specifically, non-strict mode is already outside the > critical path today and so there's no need to optimize it. I'm > probably not explaining myself clearly, but I guess i'm thinking: > > a) today for strict, unmap is in the critical path and it's important > to get it out of there. Getting it out of the critical path is so > important that we're willing to over-invalidate to speed up the > critical path. > > b) today for non-strict, unmap is not in the critical path. > > So I would almost expect your patch to _disable_ your new feature for > non-strict mappings, not auto-enable your new feature for non-strict > mappings. > > If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin > was the one that suggested the behavior you're implementing, so it's > more likely he's right than I am. ;-) > Thanks for taking a look. Non-strict mode is only for leaf entries and dma domains and this optimization is for non-leaf entries and is applicable for both, see __arm_lpae_unmap(). In other words, if you have iommu.strict=0 (non-strict mode) and try unmapping a large sg buffer as the problem described in the commit text, you would still go via this path in unmap and see the delay without this patch. So what Robin suggested is that, let's do this unconditionally for all users with non-strict mode as opposed to only restricting it to implementation specific in case of strict mode. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list 2021-06-21 5:47 ` Sai Prakash Ranjan (?) @ 2021-06-21 16:30 ` Robin Murphy -1 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 16:30 UTC (permalink / raw) To: Sai Prakash Ranjan, Doug Anderson Cc: Will Deacon, Joerg Roedel, iommu, Linux ARM, LKML, linux-arm-msm, Bjorn Andersson, Krishna Reddy, Thierry Reding, Tomasz Figa On 2021-06-21 06:47, Sai Prakash Ranjan wrote: > Hi, > > On 2021-06-19 03:39, Doug Anderson wrote: >> Hi, >> >> On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan >> <saiprakash.ranjan@codeaurora.org> wrote: >>> >>> Currently for iommu_unmap() of large scatter-gather list with page size >>> elements, the majority of time is spent in flushing of partial walks in >>> __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >>> page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support >>> range based invalidations like on arm-smmu-v3.2. >>> >>> For example: to unmap a 32MB scatter-gather list with page size elements >>> (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB >>> for 4K granule) and each of 2MB will further result in 512 TLBIVAs >>> (2MB/4K) >>> resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge >>> overhead. >>> >>> So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate >>> the entire context for partial walk flush on select few platforms where >>> cost of over-invalidation is less than unmap latency >> >> It would probably be worth punching this description up a little bit. >> Elsewhere you said in more detail why this over-invalidation is less >> of a big deal for the Qualcomm SMMU. It's probably worth saying >> something like that here, too. Like this bit paraphrased from your >> other email: >> >> On qcom impl, we have several performance improvements for TLB cache >> invalidations in HW like wait-for-safe (for realtime clients such as >> camera and display) and few others to allow for cache lookups/updates >> when TLBI is in progress for the same context bank. >> > > Sure will add this info as well in the next version. > >> >>> using the newly >>> introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for >>> non-strict mode given its all about over-invalidation saving time on >>> individual unmaps and non-deterministic generally. >> >> As per usual I'm mostly clueless, but I don't quite understand why you >> want this new behavior for non-strict mode. To me it almost seems like >> the opposite? Specifically, non-strict mode is already outside the >> critical path today and so there's no need to optimize it. I'm >> probably not explaining myself clearly, but I guess i'm thinking: >> >> a) today for strict, unmap is in the critical path and it's important >> to get it out of there. Getting it out of the critical path is so >> important that we're willing to over-invalidate to speed up the >> critical path. >> >> b) today for non-strict, unmap is not in the critical path. >> >> So I would almost expect your patch to _disable_ your new feature for >> non-strict mappings, not auto-enable your new feature for non-strict >> mappings. >> >> If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin >> was the one that suggested the behavior you're implementing, so it's >> more likely he's right than I am. ;-) >> > > Thanks for taking a look. Non-strict mode is only for leaf entries and > dma domains and this optimization is for non-leaf entries and is applicable > for both, see __arm_lpae_unmap(). In other words, if you have > iommu.strict=0 > (non-strict mode) and try unmapping a large sg buffer as the problem > described > in the commit text, you would still go via this path in unmap and see the > delay without this patch. So what Robin suggested is that, let's do this > unconditionally for all users with non-strict mode as opposed to only > restricting it to implementation specific in case of strict mode. Right, unmapping tables works out as a bit of a compromise for non-strict mode - we don't use a freelist to defer the freeing of pagetable pages, so we rely on making non-leaf invalidations synchronously to knock out walk caches which may be pointing to the page beforte we free it. We might actually be able to get away without that for non-strict unmaps, since partial walks pointing at freed memory probably aren't too much more hazardous than the equivalent leaf TLB entries while the IOVA region is held in the flush queue, but it certainly does matter for maps when we're knocking out a (presumably empty) table entry to put down a new block whose IOVA will be immediately live. Robin. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-21 16:30 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 16:30 UTC (permalink / raw) To: Sai Prakash Ranjan, Doug Anderson Cc: Tomasz Figa, linux-arm-msm, Joerg Roedel, LKML, Bjorn Andersson, iommu, Thierry Reding, Will Deacon, Linux ARM On 2021-06-21 06:47, Sai Prakash Ranjan wrote: > Hi, > > On 2021-06-19 03:39, Doug Anderson wrote: >> Hi, >> >> On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan >> <saiprakash.ranjan@codeaurora.org> wrote: >>> >>> Currently for iommu_unmap() of large scatter-gather list with page size >>> elements, the majority of time is spent in flushing of partial walks in >>> __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >>> page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support >>> range based invalidations like on arm-smmu-v3.2. >>> >>> For example: to unmap a 32MB scatter-gather list with page size elements >>> (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB >>> for 4K granule) and each of 2MB will further result in 512 TLBIVAs >>> (2MB/4K) >>> resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge >>> overhead. >>> >>> So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate >>> the entire context for partial walk flush on select few platforms where >>> cost of over-invalidation is less than unmap latency >> >> It would probably be worth punching this description up a little bit. >> Elsewhere you said in more detail why this over-invalidation is less >> of a big deal for the Qualcomm SMMU. It's probably worth saying >> something like that here, too. Like this bit paraphrased from your >> other email: >> >> On qcom impl, we have several performance improvements for TLB cache >> invalidations in HW like wait-for-safe (for realtime clients such as >> camera and display) and few others to allow for cache lookups/updates >> when TLBI is in progress for the same context bank. >> > > Sure will add this info as well in the next version. > >> >>> using the newly >>> introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for >>> non-strict mode given its all about over-invalidation saving time on >>> individual unmaps and non-deterministic generally. >> >> As per usual I'm mostly clueless, but I don't quite understand why you >> want this new behavior for non-strict mode. To me it almost seems like >> the opposite? Specifically, non-strict mode is already outside the >> critical path today and so there's no need to optimize it. I'm >> probably not explaining myself clearly, but I guess i'm thinking: >> >> a) today for strict, unmap is in the critical path and it's important >> to get it out of there. Getting it out of the critical path is so >> important that we're willing to over-invalidate to speed up the >> critical path. >> >> b) today for non-strict, unmap is not in the critical path. >> >> So I would almost expect your patch to _disable_ your new feature for >> non-strict mappings, not auto-enable your new feature for non-strict >> mappings. >> >> If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin >> was the one that suggested the behavior you're implementing, so it's >> more likely he's right than I am. ;-) >> > > Thanks for taking a look. Non-strict mode is only for leaf entries and > dma domains and this optimization is for non-leaf entries and is applicable > for both, see __arm_lpae_unmap(). In other words, if you have > iommu.strict=0 > (non-strict mode) and try unmapping a large sg buffer as the problem > described > in the commit text, you would still go via this path in unmap and see the > delay without this patch. So what Robin suggested is that, let's do this > unconditionally for all users with non-strict mode as opposed to only > restricting it to implementation specific in case of strict mode. Right, unmapping tables works out as a bit of a compromise for non-strict mode - we don't use a freelist to defer the freeing of pagetable pages, so we rely on making non-leaf invalidations synchronously to knock out walk caches which may be pointing to the page beforte we free it. We might actually be able to get away without that for non-strict unmaps, since partial walks pointing at freed memory probably aren't too much more hazardous than the equivalent leaf TLB entries while the IOVA region is held in the flush queue, but it certainly does matter for maps when we're knocking out a (presumably empty) table entry to put down a new block whose IOVA will be immediately live. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list @ 2021-06-21 16:30 ` Robin Murphy 0 siblings, 0 replies; 31+ messages in thread From: Robin Murphy @ 2021-06-21 16:30 UTC (permalink / raw) To: Sai Prakash Ranjan, Doug Anderson Cc: linux-arm-msm, LKML, iommu, Thierry Reding, Will Deacon, Linux ARM On 2021-06-21 06:47, Sai Prakash Ranjan wrote: > Hi, > > On 2021-06-19 03:39, Doug Anderson wrote: >> Hi, >> >> On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan >> <saiprakash.ranjan@codeaurora.org> wrote: >>> >>> Currently for iommu_unmap() of large scatter-gather list with page size >>> elements, the majority of time is spent in flushing of partial walks in >>> __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >>> page-by-page on iommus like arm-smmu-v2 (TLBIVA) which do not support >>> range based invalidations like on arm-smmu-v3.2. >>> >>> For example: to unmap a 32MB scatter-gather list with page size elements >>> (8192 entries), there are 16->2MB buffer unmaps based on the pgsize (2MB >>> for 4K granule) and each of 2MB will further result in 512 TLBIVAs >>> (2MB/4K) >>> resulting in a total of 8192 TLBIVAs (512*16) for 16->2MB causing a huge >>> overhead. >>> >>> So instead use tlb_flush_all() callback (TLBIALL/TLBIASID) to invalidate >>> the entire context for partial walk flush on select few platforms where >>> cost of over-invalidation is less than unmap latency >> >> It would probably be worth punching this description up a little bit. >> Elsewhere you said in more detail why this over-invalidation is less >> of a big deal for the Qualcomm SMMU. It's probably worth saying >> something like that here, too. Like this bit paraphrased from your >> other email: >> >> On qcom impl, we have several performance improvements for TLB cache >> invalidations in HW like wait-for-safe (for realtime clients such as >> camera and display) and few others to allow for cache lookups/updates >> when TLBI is in progress for the same context bank. >> > > Sure will add this info as well in the next version. > >> >>> using the newly >>> introduced quirk IO_PGTABLE_QUIRK_TLB_INV_ALL. We also do this for >>> non-strict mode given its all about over-invalidation saving time on >>> individual unmaps and non-deterministic generally. >> >> As per usual I'm mostly clueless, but I don't quite understand why you >> want this new behavior for non-strict mode. To me it almost seems like >> the opposite? Specifically, non-strict mode is already outside the >> critical path today and so there's no need to optimize it. I'm >> probably not explaining myself clearly, but I guess i'm thinking: >> >> a) today for strict, unmap is in the critical path and it's important >> to get it out of there. Getting it out of the critical path is so >> important that we're willing to over-invalidate to speed up the >> critical path. >> >> b) today for non-strict, unmap is not in the critical path. >> >> So I would almost expect your patch to _disable_ your new feature for >> non-strict mappings, not auto-enable your new feature for non-strict >> mappings. >> >> If I'm babbling, feel free to ignore. ;-) Looking back, I guess Robin >> was the one that suggested the behavior you're implementing, so it's >> more likely he's right than I am. ;-) >> > > Thanks for taking a look. Non-strict mode is only for leaf entries and > dma domains and this optimization is for non-leaf entries and is applicable > for both, see __arm_lpae_unmap(). In other words, if you have > iommu.strict=0 > (non-strict mode) and try unmapping a large sg buffer as the problem > described > in the commit text, you would still go via this path in unmap and see the > delay without this patch. So what Robin suggested is that, let's do this > unconditionally for all users with non-strict mode as opposed to only > restricting it to implementation specific in case of strict mode. Right, unmapping tables works out as a bit of a compromise for non-strict mode - we don't use a freelist to defer the freeing of pagetable pages, so we rely on making non-leaf invalidations synchronously to knock out walk caches which may be pointing to the page beforte we free it. We might actually be able to get away without that for non-strict unmaps, since partial walks pointing at freed memory probably aren't too much more hazardous than the equivalent leaf TLB entries while the IOVA region is held in the flush queue, but it certainly does matter for maps when we're knocking out a (presumably empty) table entry to put down a new block whose IOVA will be immediately live. Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCHv2 3/3] iommu/arm-smmu-qcom: Set IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC impl 2021-06-18 2:51 ` Sai Prakash Ranjan @ 2021-06-18 2:51 ` Sai Prakash Ranjan -1 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm, Bjorn Andersson, Douglas Anderson, Krishna Reddy, Thierry Reding, Tomasz Figa, Sai Prakash Ranjan Set the pgtable quirk IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC implementation to use ::tlb_flush_all() for partial walk flush to improve unmap performance. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index 7771d40176de..b8ae51592d00 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -146,6 +146,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, { struct adreno_smmu_priv *priv; + pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_TLB_INV_ALL; + /* Only enable split pagetables for the GPU device (SID 0) */ if (!qcom_adreno_smmu_is_gpu_device(dev)) return 0; @@ -185,6 +187,14 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = { { } }; +static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain, + struct io_pgtable_cfg *pgtbl_cfg, struct device *dev) +{ + pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_TLB_INV_ALL; + + return 0; +} + static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu) { unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1); @@ -308,6 +318,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu) } static const struct arm_smmu_impl qcom_smmu_impl = { + .init_context = qcom_smmu_init_context, .cfg_probe = qcom_smmu_cfg_probe, .def_domain_type = qcom_smmu_def_domain_type, .reset = qcom_smmu500_reset, -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCHv2 3/3] iommu/arm-smmu-qcom: Set IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC impl @ 2021-06-18 2:51 ` Sai Prakash Ranjan 0 siblings, 0 replies; 31+ messages in thread From: Sai Prakash Ranjan @ 2021-06-18 2:51 UTC (permalink / raw) To: Will Deacon, Robin Murphy, Joerg Roedel Cc: Thierry Reding, linux-arm-msm, Douglas Anderson, linux-kernel, iommu, linux-arm-kernel Set the pgtable quirk IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC implementation to use ::tlb_flush_all() for partial walk flush to improve unmap performance. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index 7771d40176de..b8ae51592d00 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -146,6 +146,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, { struct adreno_smmu_priv *priv; + pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_TLB_INV_ALL; + /* Only enable split pagetables for the GPU device (SID 0) */ if (!qcom_adreno_smmu_is_gpu_device(dev)) return 0; @@ -185,6 +187,14 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = { { } }; +static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain, + struct io_pgtable_cfg *pgtbl_cfg, struct device *dev) +{ + pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_TLB_INV_ALL; + + return 0; +} + static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu) { unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1); @@ -308,6 +318,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu) } static const struct arm_smmu_impl qcom_smmu_impl = { + .init_context = qcom_smmu_init_context, .cfg_probe = qcom_smmu_cfg_probe, .def_domain_type = qcom_smmu_def_domain_type, .reset = qcom_smmu500_reset, -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 31+ messages in thread
end of thread, other threads:[~2021-06-23 13:43 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-18 2:51 [PATCHv2 0/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list Sai Prakash Ranjan 2021-06-18 2:51 ` Sai Prakash Ranjan 2021-06-18 2:51 ` [PATCHv2 1/3] iommu/io-pgtable: Add a quirk to use tlb_flush_all() for partial walk flush Sai Prakash Ranjan 2021-06-18 2:51 ` Sai Prakash Ranjan 2021-06-21 15:45 ` Robin Murphy 2021-06-21 15:45 ` Robin Murphy 2021-06-21 15:45 ` Robin Murphy 2021-06-22 7:11 ` Sai Prakash Ranjan 2021-06-22 7:11 ` Sai Prakash Ranjan 2021-06-22 12:11 ` Robin Murphy 2021-06-22 12:11 ` Robin Murphy 2021-06-22 12:11 ` Robin Murphy 2021-06-22 14:27 ` Sai Prakash Ranjan 2021-06-22 14:27 ` Sai Prakash Ranjan 2021-06-22 18:37 ` Robin Murphy 2021-06-22 18:37 ` Robin Murphy 2021-06-22 18:37 ` Robin Murphy 2021-06-23 13:43 ` Sai Prakash Ranjan 2021-06-23 13:43 ` Sai Prakash Ranjan 2021-06-18 2:51 ` [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list Sai Prakash Ranjan 2021-06-18 2:51 ` Sai Prakash Ranjan 2021-06-18 22:09 ` Doug Anderson 2021-06-18 22:09 ` Doug Anderson 2021-06-18 22:09 ` Doug Anderson 2021-06-21 5:47 ` Sai Prakash Ranjan 2021-06-21 5:47 ` Sai Prakash Ranjan 2021-06-21 16:30 ` Robin Murphy 2021-06-21 16:30 ` Robin Murphy 2021-06-21 16:30 ` Robin Murphy 2021-06-18 2:51 ` [PATCHv2 3/3] iommu/arm-smmu-qcom: Set IO_PGTABLE_QUIRK_TLB_INV_ALL for QTI SoC impl Sai Prakash Ranjan 2021-06-18 2:51 ` Sai Prakash Ranjan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.