Re: [PATCHv7 2/7] iommu/arm-smmu: Add domain attribute for system cache
On 2020-11-10 17:48, Will Deacon wrote:
On Fri, Oct 30, 2020 at 02:53:09PM +0530, Sai Prakash Ranjan wrote:
Add iommu domain attribute for using system cache aka last level
cache by client drivers like GPU to set right attributes for caching
the hardware pagetables into the system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
include/linux/iommu.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index b1cf8f0abc29..070d13f80c7e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct
iommu_domain *domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+ if (smmu_domain->sys_cache)
+ pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1520,6 +1523,9 @@ static int arm_smmu_domain_get_attr(struct
iommu_domain *domain,
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
*(int *)data = smmu_domain->non_strict;
return 0;
+ case DOMAIN_ATTR_SYS_CACHE:
+ *((int *)data) = smmu_domain->sys_cache;
+ return 0;
default:
return -ENODEV;
}
@@ -1551,6 +1557,17 @@ static int arm_smmu_domain_set_attr(struct
iommu_domain *domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+ case DOMAIN_ATTR_SYS_CACHE:
+ if (smmu_domain->smmu) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ if (*((int *)data))
+ smmu_domain->sys_cache = true;
+ else
+ smmu_domain->sys_cache = false;
+ break;
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 885840f3bec8..dfc44d806671 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -373,6 +373,7 @@ struct arm_smmu_domain {
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t cb_lock; /* Serialises ATS1* ops and
TLB syncs */
struct iommu_domain domain;
+ boolsys_cache;
};
struct arm_smmu_master_cfg {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..4f4bb9c6f8f6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+ DOMAIN_ATTR_SYS_CACHE,
I think you're trying to make this look generic, but it's really not.
If we need to funnel io-pgtable quirks through domain attributes, then
I
think we should be open about that and add something like
DOMAIN_ATTR_IO_PGTABLE_CFG which could take a struct of page-table
configuration data for the domain (this could just be quirks initially,
but maybe it's worth extending to take ias, oas and page size)
Actually the initial versions used DOMAIN_ATTR_QCOM_SYS_CACHE
to make it QCOM specific and not generic, I don't see anyone else
using this attribute, would that work?
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
Re: [PATCHv7 1/7] iommu/io-pgtable-arm: Add support to use system cache
On 2020-11-10 17:48, Will Deacon wrote:
On Fri, Oct 30, 2020 at 02:53:08PM +0530, Sai Prakash Ranjan wrote:
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 7 ++-
include/linux/io-pgtable.h | 4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c
b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..a356caf1683a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,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_TTBR1 |
+ IO_PGTABLE_QUIRK_SYS_CACHE))
return NULL;
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,6 +774,10 @@ arm_64_lpae_alloc_pgtable_s1(struct
io_pgtable_cfg *cfg, void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+ } else if (cfg->quirks & IO_PGTABLE_QUIRK_SYS_CACHE) {
+ tcr->sh = ARM_LPAE_TCR_SH_OS;
+ tcr->irgn = ARM_LPAE_TCR_RGN_NC;
+ tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
Given that this only applies in the case where then page-table walker
is
non-coherent, I think we'd be better off renaming the quirk to
something
like IO_PGTABLE_QUIRK_ARM_OUTER_WBWA and then rejecting it in the
non-coherent case.
Do you mean like below?
diff --git a/drivers/iommu/io-pgtable-arm.c
b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..94de1f71db42 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -776,7 +776,10 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg
*cfg, void *cookie)
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
- tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+ if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
+ tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+ else
+ tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
}
tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
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
Re: [PATCH v3 00/14] iommu/amd: Add Generic IO Page Table Framework Support
Hi Joerg, Do you have any update on this series? Thanks, Suravee On 11/2/20 10:16 AM, Suravee Suthikulpanit wrote: Joerg, You mentioned to remind you to pull this in to linux-next. Thanks, Suravee On 10/4/20 8:45 AM, Suravee Suthikulpanit wrote: The framework allows callable implementation of IO page table. This allows AMD IOMMU driver to switch between different types of AMD IOMMU page tables (e.g. v1 vs. v2). This series refactors the current implementation of AMD IOMMU v1 page table to adopt the framework. There should be no functional change. Subsequent series will introduce support for the AMD IOMMU v2 page table. Thanks, Suravee Change from V2 (https://lore.kernel.org/lkml/835c0d46-ed96-9fbe-856a-777dcffac...@amd.com/T/#t) - Patch 2/14: Introduce helper function io_pgtable_cfg_to_data. - Patch 13/14: Put back the struct iommu_flush_ops since patch v2 would run into NULL pointer bug when calling free_io_pgtable_ops if not defined. Change from V1 (https://lkml.org/lkml/2020/9/23/251) - Do not specify struct io_pgtable_cfg.coherent_walk, since it is not currently used. (per Robin) - Remove unused struct iommu_flush_ops. (patch 2/13) - Move amd_iommu_setup_io_pgtable_ops to iommu.c instead of io_pgtable.c patch 13/13) Suravee Suthikulpanit (14): iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline iommu/amd: Prepare for generic IO page table framework iommu/amd: Move pt_root to to struct amd_io_pgtable iommu/amd: Convert to using amd_io_pgtable iommu/amd: Declare functions as extern iommu/amd: Move IO page table related functions iommu/amd: Restructure code for freeing page table iommu/amd: Remove amd_iommu_domain_get_pgtable iommu/amd: Rename variables to be consistent with struct io_pgtable_ops iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable iommu/amd: Introduce iommu_v1_iova_to_phys iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page iommu/amd: Introduce IOMMU flush callbacks iommu/amd: Adopt IO page table framework drivers/iommu/amd/Kconfig | 1 + drivers/iommu/amd/Makefile | 2 +- drivers/iommu/amd/amd_iommu.h | 22 + drivers/iommu/amd/amd_iommu_types.h | 43 +- drivers/iommu/amd/io_pgtable.c | 564 drivers/iommu/amd/iommu.c | 646 +++- drivers/iommu/io-pgtable.c | 3 + include/linux/io-pgtable.h | 2 + 8 files changed, 691 insertions(+), 592 deletions(-) create mode 100644 drivers/iommu/amd/io_pgtable.c ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/vt-d: avoid unnecessory panic if iommu init fail in tboot system
Hi Zhenzhong,
On 11/10/20 3:19 PM, Zhenzhong Duan wrote:
"intel_iommu=off" command line is used to disable iommu but iommu is force
enabled in a tboot system for security reason.
However for better performance on high speed network device, a new option
"intel_iommu=tboot_noforce" is introduced to disable the force on.
By default kernel should panic if iommu init fail in tboot for security
reason, but it's unnecessory if we use "intel_iommu=tboot_noforce,off".
Fix the code setting force_on and move intel_iommu_tboot_noforce
from tboot code to intel iommu code.
Fixes: 7304e8f28bb2 ("iommu/vt-d: Correctly disable Intel IOMMU force on")
Signed-off-by: Zhenzhong Duan
Thanks for the patch.
Acked-by: Lu Baolu
Best regards,
baolu
---
v2: move ckeck of intel_iommu_tboot_noforce into iommu code per Baolu.
arch/x86/kernel/tboot.c | 3 ---
drivers/iommu/intel/iommu.c | 5 +++--
include/linux/intel-iommu.h | 1 -
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 992fb14..420be87 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -514,9 +514,6 @@ int tboot_force_iommu(void)
if (!tboot_enabled())
return 0;
- if (intel_iommu_tboot_noforce)
- return 1;
-
if (no_iommu || swiotlb || dmar_disabled)
pr_warn("Forcing Intel-IOMMU to enabled\n");
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 1b1ca63..4d9b298 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -179,7 +179,7 @@ static inline unsigned long virt_to_dma_pfn(void *p)
* (used when kernel is launched w/ TXT)
*/
static int force_on = 0;
-int intel_iommu_tboot_noforce;
+static int intel_iommu_tboot_noforce;
static int no_platform_optin;
#define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry))
@@ -4885,7 +4885,8 @@ int __init intel_iommu_init(void)
* Intel IOMMU is required for a TXT/tboot launch or platform
* opt in, so enforce that.
*/
- force_on = tboot_force_iommu() || platform_optin_force_iommu();
+ force_on = (!intel_iommu_tboot_noforce && tboot_force_iommu()) ||
+ platform_optin_force_iommu();
if (iommu_init_mempool()) {
if (force_on)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index fbf5b3e..d956987 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -798,7 +798,6 @@ struct context_entry *iommu_context_addr(struct intel_iommu
*iommu, u8 bus,
extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
extern int dmar_disabled;
extern int intel_iommu_enabled;
-extern int intel_iommu_tboot_noforce;
extern int intel_iommu_gfx_mapped;
#else
static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v3 1/2] dma-mapping: add benchmark support for streaming DMA APIs
> -Original Message-
> From: John Garry
> Sent: Tuesday, November 10, 2020 9:39 PM
> To: Song Bao Hua (Barry Song) ;
> iommu@lists.linux-foundation.org; h...@lst.de; robin.mur...@arm.com;
> m.szyprow...@samsung.com
> Cc: linux-kselft...@vger.kernel.org; Will Deacon ; Joerg
> Roedel ; Linuxarm ; xuwei (O)
> ; Shuah Khan
> Subject: Re: [PATCH v3 1/2] dma-mapping: add benchmark support for
> streaming DMA APIs
>
> On 10/11/2020 08:10, Song Bao Hua (Barry Song) wrote:
> > Hello Robin, Christoph,
> > Any further comment? John suggested that "depends on DEBUG_FS" should
> be added in Kconfig.
> > I am collecting more comments to send v4 together with fixing this minor
> issue :-)
> >
> > Thanks
> > Barry
> >
> >> -Original Message-
> >> From: Song Bao Hua (Barry Song)
> >> Sent: Monday, November 2, 2020 9:07 PM
> >> To: iommu@lists.linux-foundation.org; h...@lst.de;
> robin.mur...@arm.com;
> >> m.szyprow...@samsung.com
> >> Cc: Linuxarm ; linux-kselft...@vger.kernel.org;
> xuwei
> >> (O) ; Song Bao Hua (Barry Song)
> >> ; Joerg Roedel ; Will
> Deacon
> >> ; Shuah Khan
> >> Subject: [PATCH v3 1/2] dma-mapping: add benchmark support for
> streaming
> >> DMA APIs
> >>
> >> Nowadays, there are increasing requirements to benchmark the
> performance
> >> of dma_map and dma_unmap particually while the device is attached to an
> >> IOMMU.
> >>
> >> This patch enables the support. Users can run specified number of threads
> to
> >> do dma_map_page and dma_unmap_page on a specific NUMA node with
> the
> >> specified duration. Then dma_map_benchmark will calculate the average
> >> latency for map and unmap.
> >>
> >> A difficulity for this benchmark is that dma_map/unmap APIs must run on a
> >> particular device. Each device might have different backend of IOMMU or
> >> non-IOMMU.
> >>
> >> So we use the driver_override to bind dma_map_benchmark to a particual
> >> device by:
> >> For platform devices:
> >> echo dma_map_benchmark >
> /sys/bus/platform/devices/xxx/driver_override
> >> echo xxx > /sys/bus/platform/drivers/xxx/unbind
> >> echo xxx > /sys/bus/platform/drivers/dma_map_benchmark/bind
> >>
>
> Hi Barry,
>
> >> For PCI devices:
> >> echo dma_map_benchmark >
> >> /sys/bus/pci/devices/:00:01.0/driver_override
> >> echo :00:01.0 > /sys/bus/pci/drivers/xxx/unbind echo :00:01.0 >
> >> /sys/bus/pci/drivers/dma_map_benchmark/bind
>
> Do we need to check if the device to which we attach actually has DMA
> mapping capability?
Hello John,
I'd like to think checking this here would be overdesign. We just give users the
freedom to bind any device they care about to the benchmark driver. Usually
that means a real hardware either behind an IOMMU or through a direct
mapping.
if for any reason users put a wrong "device", that is the choice of users.
Anyhow,
the below code will still handle it properly and users will get a report in
which
everything is zero.
+static int map_benchmark_thread(void *data)
+{
...
+ dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE,
DMA_BIDIRECTIONAL);
+ if (unlikely(dma_mapping_error(map->dev, dma_addr))) {
+ pr_err("dma_map_single failed on %s\n",
dev_name(map->dev));
+ ret = -ENOMEM;
+ goto out;
+ }
...
+}
>
> >>
> >> Cc: Joerg Roedel
> >> Cc: Will Deacon
> >> Cc: Shuah Khan
> >> Cc: Christoph Hellwig
> >> Cc: Marek Szyprowski
> >> Cc: Robin Murphy
> >> Signed-off-by: Barry Song
> >> ---
>
> Thanks,
> John
Thanks
Barry
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/vt-d: avoid unnecessory panic if iommu init fail in tboot system
Hi Lukasz,
On Tue, Nov 10, 2020 at 11:53 PM Lukasz Hawrylko
wrote:
>
> Hi Zhenzhong
>
> On Tue, 2020-11-10 at 15:19 +0800, Zhenzhong Duan wrote:
> > "intel_iommu=off" command line is used to disable iommu but iommu is force
> > enabled in a tboot system for security reason.
> >
> > However for better performance on high speed network device, a new option
> > "intel_iommu=tboot_noforce" is introduced to disable the force on.
> >
> > By default kernel should panic if iommu init fail in tboot for security
> > reason, but it's unnecessory if we use "intel_iommu=tboot_noforce,off".
> >
> > Fix the code setting force_on and move intel_iommu_tboot_noforce
> > from tboot code to intel iommu code.
> >
> > Fixes: 7304e8f28bb2 ("iommu/vt-d: Correctly disable Intel IOMMU force on")
> > Signed-off-by: Zhenzhong Duan
> > ---
> > v2: move ckeck of intel_iommu_tboot_noforce into iommu code per Baolu.
>
> I have check it on my TXT testing environment with latest TBOOT,
> everything works as expected.
Thanks very much for help checking, may I have your Tested-by?
Zhenzhong
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 03/15] PCI/P2PDMA: Introduce pci_p2pdma_should_map_bus() and pci_p2pdma_bus_offset()
On 2020-11-10 4:25 p.m., Bjorn Helgaas wrote:
> On Fri, Nov 06, 2020 at 10:00:24AM -0700, Logan Gunthorpe wrote:
>> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
>> dma map functions to determine how to map a given p2pdma page.
>
> s/dma/DMA/ for consistency (also below in function comment)
>
>> pci_p2pdma_bus_offset() is also added to allow callers to get the bus
>> offset if they need to map the bus address.
>>
>> Signed-off-by: Logan Gunthorpe
>> ---
>> drivers/pci/p2pdma.c | 46 ++
>> include/linux/pci-p2pdma.h | 11 +
>> 2 files changed, 57 insertions(+)
>>
>> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
>> index ea8472278b11..9961e779f430 100644
>> --- a/drivers/pci/p2pdma.c
>> +++ b/drivers/pci/p2pdma.c
>> @@ -930,6 +930,52 @@ void pci_p2pdma_unmap_sg_attrs(struct device *dev,
>> struct scatterlist *sg,
>> }
>> EXPORT_SYMBOL_GPL(pci_p2pdma_unmap_sg_attrs);
>>
>> +/**
>> + * pci_p2pdma_bus_offset - returns the bus offset for a given page
>> + * @page: page to get the offset for
>> + *
>> + * Must be passed a pci p2pdma page.
>
> s/pci/PCI/
>
>> + */
>> +u64 pci_p2pdma_bus_offset(struct page *page)
>> +{
>> +struct pci_p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(page->pgmap);
>> +
>> +WARN_ON(!is_pci_p2pdma_page(page));
>> +
>> +return p2p_pgmap->bus_offset;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_p2pdma_bus_offset);
>> +
>> +/**
>> + * pci_p2pdma_should_map_bus - determine if a dma mapping should use the
>> + * bus address
>> + * @dev: device doing the DMA request
>> + * @pgmap: dev_pagemap structure for the mapping
>> + *
>> + * Returns 1 if the page should be mapped with a bus address, 0 otherwise
>> + * and -1 the device should not be mapping P2PDMA pages.
>
> I think this is missing a word.
>
> I'm not really sure how to interpret the "should" in
> pci_p2pdma_should_map_bus(). If this returns -1, does that mean the
> patches *cannot* be mapped? They *could* be mapped, but you really
> *shouldn't*? Something else?
>
> 1 means page should be mapped with bus address. 0 means ... what,
> exactly? It should be mapped with some different address?
1 means it must be mapped with a bus address
0 means it may be mapped normally (through the IOMMU or just with a
direct physical address)
-1 means it cannot be mapped and should fail (ie. if it must go through
the IOMMU, but the IOMMU is not in the whitelist).
> Sorry these are naive questions because I don't know how all this
> works.
Thanks for the review. Definitely points out some questionable language
that I used. I'll reword this if/when it goes further.
Logan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 03/15] PCI/P2PDMA: Introduce pci_p2pdma_should_map_bus() and pci_p2pdma_bus_offset()
On Fri, Nov 06, 2020 at 10:00:24AM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
> dma map functions to determine how to map a given p2pdma page.
s/dma/DMA/ for consistency (also below in function comment)
> pci_p2pdma_bus_offset() is also added to allow callers to get the bus
> offset if they need to map the bus address.
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/pci/p2pdma.c | 46 ++
> include/linux/pci-p2pdma.h | 11 +
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index ea8472278b11..9961e779f430 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -930,6 +930,52 @@ void pci_p2pdma_unmap_sg_attrs(struct device *dev,
> struct scatterlist *sg,
> }
> EXPORT_SYMBOL_GPL(pci_p2pdma_unmap_sg_attrs);
>
> +/**
> + * pci_p2pdma_bus_offset - returns the bus offset for a given page
> + * @page: page to get the offset for
> + *
> + * Must be passed a pci p2pdma page.
s/pci/PCI/
> + */
> +u64 pci_p2pdma_bus_offset(struct page *page)
> +{
> + struct pci_p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(page->pgmap);
> +
> + WARN_ON(!is_pci_p2pdma_page(page));
> +
> + return p2p_pgmap->bus_offset;
> +}
> +EXPORT_SYMBOL_GPL(pci_p2pdma_bus_offset);
> +
> +/**
> + * pci_p2pdma_should_map_bus - determine if a dma mapping should use the
> + * bus address
> + * @dev: device doing the DMA request
> + * @pgmap: dev_pagemap structure for the mapping
> + *
> + * Returns 1 if the page should be mapped with a bus address, 0 otherwise
> + * and -1 the device should not be mapping P2PDMA pages.
I think this is missing a word.
I'm not really sure how to interpret the "should" in
pci_p2pdma_should_map_bus(). If this returns -1, does that mean the
patches *cannot* be mapped? They *could* be mapped, but you really
*shouldn't*? Something else?
1 means page should be mapped with bus address. 0 means ... what,
exactly? It should be mapped with some different address?
Sorry these are naive questions because I don't know how all this
works.
> + */
> +int pci_p2pdma_should_map_bus(struct device *dev, struct dev_pagemap *pgmap)
> +{
> + struct pci_p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(pgmap);
> + struct pci_dev *client;
> +
> + if (!dev_is_pci(dev))
> + return -1;
> +
> + client = to_pci_dev(dev);
> +
> + switch (pci_p2pdma_map_type(p2p_pgmap->provider, client)) {
> + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> + return 0;
> + case PCI_P2PDMA_MAP_BUS_ADDR:
> + return 1;
> + default:
> + return -1;
> + }
> +}
> +EXPORT_SYMBOL_GPL(pci_p2pdma_should_map_bus);
> +
> /**
> * pci_p2pdma_enable_store - parse a configfs/sysfs attribute store
> * to enable p2pdma
> diff --git a/include/linux/pci-p2pdma.h b/include/linux/pci-p2pdma.h
> index 8318a97c9c61..fc5de47eeac4 100644
> --- a/include/linux/pci-p2pdma.h
> +++ b/include/linux/pci-p2pdma.h
> @@ -34,6 +34,8 @@ int pci_p2pdma_map_sg_attrs(struct device *dev, struct
> scatterlist *sg,
> int nents, enum dma_data_direction dir, unsigned long attrs);
> void pci_p2pdma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg,
> int nents, enum dma_data_direction dir, unsigned long attrs);
> +u64 pci_p2pdma_bus_offset(struct page *page);
> +int pci_p2pdma_should_map_bus(struct device *dev, struct dev_pagemap *pgmap);
> int pci_p2pdma_enable_store(const char *page, struct pci_dev **p2p_dev,
> bool *use_p2pdma);
> ssize_t pci_p2pdma_enable_show(char *page, struct pci_dev *p2p_dev,
> @@ -83,6 +85,15 @@ static inline void pci_p2pmem_free_sgl(struct pci_dev
> *pdev,
> static inline void pci_p2pmem_publish(struct pci_dev *pdev, bool publish)
> {
> }
> +static inline u64 pci_p2pdma_bus_offset(struct page *page)
> +{
> + return -1;
> +}
> +static inline int pci_p2pdma_should_map_bus(struct device *dev,
> + struct dev_pagemap *pgmap)
> +{
> + return -1;
> +}
> static inline int pci_p2pdma_map_sg_attrs(struct device *dev,
> struct scatterlist *sg, int nents, enum dma_data_direction dir,
> unsigned long attrs)
> --
> 2.20.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH for-5.10] swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single
On Tue, Nov 10, 2020 at 10:14:21AM +0100, Christoph Hellwig wrote: > On Wed, Nov 04, 2020 at 09:04:38AM -0500, Konrad Rzeszutek Wilk wrote: > > On Tue, Nov 03, 2020 at 10:46:43AM +0100, Christoph Hellwig wrote: > > > ping? > > > > Hopefully this goes through. I am in the process of testing it but ran > > into testing issues that I believe are unrelated. > > Did you manage to make any progress? This fixes an issue with the YES!! > new support for systems with DMA offsets in 5.10.. OK. Sending the git pull request in a minute or two. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property
On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote: > On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote: > > On 2020-11-05 16:43, Thierry Reding wrote: > > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote: > > > > On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote: > > > > > On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote: > > > > > > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote: > > > > > > > From: Thierry Reding > > > > > > > > > > > > > > Reserved memory regions can be marked as "active" if hardware is > > > > > > > expected to access the regions during boot and before the > > > > > > > operating > > > > > > > system can take control. One example where this is useful is for > > > > > > > the > > > > > > > operating system to infer whether the region needs to be identity- > > > > > > > mapped through an IOMMU. > > > > > > > > > > > > I like simple solutions, but this hardly seems adequate to solve the > > > > > > problem of passing IOMMU setup from bootloader/firmware to the OS. > > > > > > Like > > > > > > what is the IOVA that's supposed to be used if identity mapping is > > > > > > not > > > > > > used? > > > > > > > > > > The assumption here is that if the region is not active there is no > > > > > need > > > > > for the IOVA to be specified because the kernel will allocate memory > > > > > and > > > > > assign any IOVA of its choosing. > > > > > > > > > > Also, note that this is not meant as a way of passing IOMMU setup from > > > > > the bootloader or firmware to the OS. The purpose of this is to > > > > > specify > > > > > that some region of memory is actively being accessed during boot. The > > > > > particular case that I'm looking at is where the bootloader set up a > > > > > splash screen and keeps it on during boot. The bootloader has not set > > > > > up > > > > > an IOMMU mapping and the identity mapping serves as a way of keeping > > > > > the > > > > > accesses by the display hardware working during the transitional > > > > > period > > > > > after the IOMMU translations have been enabled by the kernel but > > > > > before > > > > > the kernel display driver has had a chance to set up its own IOMMU > > > > > mappings. > > > > > > > > > > > If you know enough about the regions to assume identity mapping, > > > > > > then > > > > > > can't you know if active or not? > > > > > > > > > > We could alternatively add some property that describes the region as > > > > > requiring an identity mapping. But note that we can't make any > > > > > assumptions here about the usage of these regions because the IOMMU > > > > > driver simply has no way of knowing what they are being used for. > > > > > > > > > > Some additional information is required in device tree for the IOMMU > > > > > driver to be able to make that decision. > > > > > > > > Rob, can you provide any hints on exactly how you want to move this > > > > forward? I don't know in what direction you'd like to proceed. > > > > > > Hi Rob, > > > > > > do you have any suggestions on how to proceed with this? I'd like to get > > > this moving again because it's something that's been nagging me for some > > > months now. It also requires changes across two levels in the bootloader > > > stack as well as Linux and it takes quite a bit of work to make all the > > > changes, so before I go and rewrite everything I'd like to get the DT > > > bindings sorted out first. > > > > > > So just to summarize why I think this simple solution is good enough: it > > > tries to solve a very narrow and simple problem. This is not an attempt > > > at describing the firmware's full IOMMU setup to the kernel. In fact, it > > > is primarily targetted at cases where the firmware hasn't setup an IOMMU > > > at all, and we just want to make sure that when the kernel takes over > > > and does want to enable the IOMMU, that all the regions that are > > > actively being accessed by non-quiesced hardware (the most typical > > > example would be a framebuffer scanning out a splat screen or animation, > > > but it could equally well be some sort of welcoming tone or music being > > > played back) are described in device tree. > > > > > > In other words, and this is perhaps better answering your second > > > question: in addition to describing reserved memory regions, we want to > > > add a bit of information here about the usage of these memory regions. > > > Some memory regions may contain information that the kernel may want to > > > use (such an external memory frequency scaling tables) and those I would > > > describe as "inactive" memory because it isn't being accessed by > > > hardware. The framebuffer in this case is the opposite and it is being > > > actively accessed (hence it is marked "active") by hardware while the > > > kernel is busy setting everything up so that it can reconfigure that > > > hardware and take over with its own framebuffer (for the console,
Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Tue, Nov 10, 2020 at 5:35 AM Linus Walleij wrote: > On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > > > Allow the qcom_scm driver to be loadable as a permenent module. > > ... > I applied this patch to the pinctrl tree as well, I suppose > that was the intention. If someone gets upset I can always > pull it out. Will: You ok with this? thanks -john ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()
On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-05 at 16:11 +, James Morse wrote: > > On 03/11/2020 17:31, Nicolas Saenz Julienne wrote: > > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay > > > ZONE_DMA's initialization after unflattening the devicetree and ACPI's > > > boot table initialization, so move it later in the boot process. > > > Specifically into mem_init(), this is the last place crashkernel will be > > > able to reserve the memory before the page allocator kicks in. > > > There > > > isn't any apparent reason for doing this earlier. > > > > It's so that map_mem() can carve it out of the linear/direct map. > > This is so that stray writes from a crashing kernel can't accidentally > > corrupt the kdump > > kernel. We depend on this if we continue with kdump, but failed to offline > > all the other > > CPUs. > > I presume here you refer to arch_kexec_protect_crashkres(), IIUC this will > only > happen further down the line, after having loaded the kdump kernel image. But > it also depends on the mappings to be PAGE sized (flags == NO_BLOCK_MAPPINGS | > NO_CONT_MAPPINGS). IIUC, arch_kexec_protect_crashkres() is only for the crashkernel image, not the whole reserved memory that the crashkernel will use. For the latter, we avoid the linear map by marking it as nomap in map_mem(). > > We also depend on this when skipping the checksum code in purgatory, which > > can be > > exceedingly slow. > > This one I don't fully understand, so I'll lazily assume the prerequisite is > the same WRT how memory is mapped. :) > > Ultimately there's also /sys/kernel/kexec_crash_size's handling. Same > prerequisite. > > Keeping in mind acpi_table_upgrade() and unflatten_device_tree() depend on > having the linear mappings available. So it looks like reserve_crashkernel() wants to reserve memory before setting up the linear map with the information about the DMA zones in place but that comes later when we can parse the firmware tables. I wonder, instead of not mapping the crashkernel reservation, can we not do an arch_kexec_protect_crashkres() for the whole reservation after we created the linear map? > Let me stress that knowing the DMA constraints in the system before reserving > crashkernel's regions is necessary if we ever want it to work seamlessly on > all > platforms. Be it small stuff like the Raspberry Pi or huge servers with TB of > memory. Indeed. So we have 3 options (so far): 1. Allow the crashkernel reservation to go into the linear map but set it to invalid once allocated. 2. Parse the flattened DT (not sure what we do with ACPI) before creating the linear map. We may have to rely on some SoC ID here instead of actual DMA ranges. 3. Assume the smallest ZONE_DMA possible on arm64 (1GB) for crashkernel reservations and not rely on arm64_dma_phys_limit in reserve_crashkernel(). I think (2) we tried hard to avoid. Option (3) brings us back to the issues we had on large crashkernel reservations regressing on some platforms (though it's been a while since, they mostly went quiet ;)). However, with Chen's crashkernel patches we end up with two reservations, one in the low DMA zone and one higher, potentially above 4GB. Having a fixed 1GB limit wouldn't be any worse for crashkernel reservations than what we have now. If (1) works, I'd go for it (James knows this part better than me), otherwise we can go for (3). -- Catalin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers
On 10/11/20 09:59, David Woodhouse wrote:
Hm, attempting to reproduce this shows something else. Ever since
commit be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-
iommu api") in 5.5 the following stops working for me:
$ qemu-system-x86_64 -serial mon:stdio -kernel bzImage -machine
q35,accel=kvm,kernel-irqchip=split -m 2G -device amd-iommu,intremap=off -append
"console=ttyS0 apic=verbose debug" -display none
It hasn't got a hard drive but I can watch the SATA interrupts fail as
it probes the CD-ROM:
[7.403327] ata3.00: qc timeout (cmd 0xa1)
[7.405980] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Adding 'iommu=off' to the kernel command line makes it work again, in
that it correctly panics at the lack of a root file system, quickly.
That might well be a QEMU bug though, AMD emulation is kinda experimental.
Paolo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/vt-d: avoid unnecessory panic if iommu init fail in tboot system
Hi Zhenzhong
On Tue, 2020-11-10 at 15:19 +0800, Zhenzhong Duan wrote:
> "intel_iommu=off" command line is used to disable iommu but iommu is force
> enabled in a tboot system for security reason.
>
> However for better performance on high speed network device, a new option
> "intel_iommu=tboot_noforce" is introduced to disable the force on.
>
> By default kernel should panic if iommu init fail in tboot for security
> reason, but it's unnecessory if we use "intel_iommu=tboot_noforce,off".
>
> Fix the code setting force_on and move intel_iommu_tboot_noforce
> from tboot code to intel iommu code.
>
> Fixes: 7304e8f28bb2 ("iommu/vt-d: Correctly disable Intel IOMMU force on")
> Signed-off-by: Zhenzhong Duan
> ---
> v2: move ckeck of intel_iommu_tboot_noforce into iommu code per Baolu.
I have check it on my TXT testing environment with latest TBOOT,
everything works as expected.
Thanks,
Lukasz
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[GIT PULL] iommu/arm-smmu: First batch of updates for 5.11
Hi Joerg, Please can you pull these Arm SMMU updates for 5.11 so that they can get into -next? I think Bjorn is keen to get a bunch of DT updates moving, so the sooner we can get this lot out there, the better. Summary in the tag. There are a few other patches kicking around on the list, so I may send a second pull on top in a couple of weeks or so. Cheers, Will --->8 The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-updates for you to fetch changes up to a29bbb0861f487a5e144dc997a9f71a36c7a2404: dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU (2020-11-10 12:25:49 +) First batch of Arm SMMU updates for 5.11 - Allow implementations to hook writes to S2CR and SCTLR registers - Handle broken Qualcomm bootloader/firmware - Support Adreno tightly-coupled SMMU implementation - Use devm_krealloc() - Use 'true' instead of '1' when assigning 'bool disable_bypass' Bjorn Andersson (3): iommu/arm-smmu: Allow implementation specific write_s2cr iommu/arm-smmu-qcom: Read back stream mappings iommu/arm-smmu-qcom: Implement S2CR quirk Jordan Crouse (2): iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU Kaixu Xia (1): iommu/arm-smmu-v3: Assign boolean values to a bool variable Rob Clark (1): iommu/arm-smmu: Add a way for implementations to influence SCTLR Robin Murphy (1): iommu/arm-smmu: Use new devm_krealloc() .../devicetree/bindings/iommu/arm,smmu.yaml| 9 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c| 2 +- drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 8 +- drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 17 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 259 - drivers/iommu/arm/arm-smmu/arm-smmu.c | 18 +- drivers/iommu/arm/arm-smmu/arm-smmu.h | 4 + 7 files changed, 284 insertions(+), 33 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v19 0/4] iommu/arm-smmu: Add adreno-smmu implementation and bindings
On Mon, 9 Nov 2020 11:47:24 -0700, Jordan Crouse wrote: > This short series adds support for the adreno-smmu implementation of the > arm-smmu driver and the device-tree bindings to turn on the implementation > for the sm845 and sc7180 GPUs. These changes are the last ones needed to > enable > per-instance pagetables in the drm/msm driver. > > v19: Rebase to kernel/git/will/linux.git for-joerg/arm-smmu/updates to pick up > system cache patches and devm_realloc() updates. Use a function hook to > modify / write sctlr > v18: No deltas in this patchset since the last go-around for 5.10 [1]. > > [...] Applied patches 1-3 to will (for-joerg/arm-smmu/updates), thanks! [1/4] iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU https://git.kernel.org/will/c/5c7469c66f95 [2/4] iommu/arm-smmu: Add a way for implementations to influence SCTLR https://git.kernel.org/will/c/bffb2eaf0ba2 [3/4] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU https://git.kernel.org/will/c/a29bbb0861f4 I assume the .dts change will be routed separately so as to avoid conflicts. Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > Allow the qcom_scm driver to be loadable as a permenent module. > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > ensure that drivers that call into the qcom_scm driver are > also built as modules. While not ideal in some cases its the > only safe way I can find to avoid build errors without having > those drivers select QCOM_SCM and have to force it on (as > QCOM_SCM=n can be valid for those drivers). > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Acked-by: Kalle Valo > Acked-by: Greg Kroah-Hartman > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz I applied this patch to the pinctrl tree as well, I suppose that was the intention. If someone gets upset I can always pull it out. Thanks for your perseverance in driving this John. Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 2/3] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > Tweaks to allow pinctrl-msm code to be loadable as a module. > > This is needed in order to support having the qcom-scm driver, > which pinctrl-msm calls into, configured as a module. > > This requires that we tweak Kconfigs selecting PINCTRL_MSM to > also depend on QCOM_SCM || QCOM_SCM=n so that we match the > module setting of QCOM_SCM. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz Patch applied! Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 1/3] pinctrl: qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then a selected config
On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > This patch reworks PINCTRL_MSM to be a visible option, and > instead of having the various SoC specific drivers select > PINCTRL_MSM, this switches those configs to depend on > PINCTRL_MSM. > > This is useful, as it will be needed in order to cleanly support > having the qcom-scm driver, which pinctrl-msm calls into, > configured as a module. Without this change, we would eventually > have to add dependency lines to every config that selects > PINCTRL_MSM, and that would becomes a maintenance headache. > > We also add PINCTRL_MSM to the arm64 defconfig to avoid > surprises as otherwise PINCTRL_MSM/IPQ* options previously > enabled, will be off. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Reviewed-by: Bjorn Andersson > Signed-off-by: John Stultz Patch applied! Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv7 1/7] iommu/io-pgtable-arm: Add support to use system cache
On Fri, Oct 30, 2020 at 02:53:08PM +0530, Sai Prakash Ranjan wrote:
> Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
> attributes set in TCR for the page table walker when
> using system cache.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/io-pgtable-arm.c | 7 ++-
> include/linux/io-pgtable.h | 4
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index a7a9bc08dcd1..a356caf1683a 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -761,7 +761,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_TTBR1 |
> + IO_PGTABLE_QUIRK_SYS_CACHE))
> return NULL;
>
> data = arm_lpae_alloc_pgtable(cfg);
> @@ -773,6 +774,10 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
> void *cookie)
> tcr->sh = ARM_LPAE_TCR_SH_IS;
> tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
> tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
> + } else if (cfg->quirks & IO_PGTABLE_QUIRK_SYS_CACHE) {
> + tcr->sh = ARM_LPAE_TCR_SH_OS;
> + tcr->irgn = ARM_LPAE_TCR_RGN_NC;
> + tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
Given that this only applies in the case where then page-table walker is
non-coherent, I think we'd be better off renaming the quirk to something
like IO_PGTABLE_QUIRK_ARM_OUTER_WBWA and then rejecting it in the
non-coherent case.
> } else {
> tcr->sh = ARM_LPAE_TCR_SH_OS;
> tcr->irgn = ARM_LPAE_TCR_RGN_NC;
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 4cde111e425b..86631f711e05 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -86,6 +86,9 @@ struct io_pgtable_cfg {
>*
>* IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
>* for use in the upper half of a split address space.
> + *
> + * IO_PGTABLE_QUIRK_SYS_CACHE: Override the attributes set in TCR for
> + * the page table walker when using system cache.
and then update this accordingly.
Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv7 2/7] iommu/arm-smmu: Add domain attribute for system cache
On Fri, Oct 30, 2020 at 02:53:09PM +0530, Sai Prakash Ranjan wrote:
> Add iommu domain attribute for using system cache aka last level
> cache by client drivers like GPU to set right attributes for caching
> the hardware pagetables into the system cache.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> include/linux/iommu.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index b1cf8f0abc29..070d13f80c7e 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> if (smmu_domain->non_strict)
> pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
>
> + if (smmu_domain->sys_cache)
> + pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
> +
> pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
> if (!pgtbl_ops) {
> ret = -ENOMEM;
> @@ -1520,6 +1523,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
> *domain,
> case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
> *(int *)data = smmu_domain->non_strict;
> return 0;
> + case DOMAIN_ATTR_SYS_CACHE:
> + *((int *)data) = smmu_domain->sys_cache;
> + return 0;
> default:
> return -ENODEV;
> }
> @@ -1551,6 +1557,17 @@ static int arm_smmu_domain_set_attr(struct
> iommu_domain *domain,
> else
> smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
> break;
> + case DOMAIN_ATTR_SYS_CACHE:
> + if (smmu_domain->smmu) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> + if (*((int *)data))
> + smmu_domain->sys_cache = true;
> + else
> + smmu_domain->sys_cache = false;
> + break;
> default:
> ret = -ENODEV;
> }
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 885840f3bec8..dfc44d806671 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -373,6 +373,7 @@ struct arm_smmu_domain {
> struct mutexinit_mutex; /* Protects smmu pointer */
> spinlock_t cb_lock; /* Serialises ATS1* ops and
> TLB syncs */
> struct iommu_domain domain;
> + boolsys_cache;
> };
>
> struct arm_smmu_master_cfg {
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index b95a6f8db6ff..4f4bb9c6f8f6 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -118,6 +118,7 @@ enum iommu_attr {
> DOMAIN_ATTR_FSL_PAMUV1,
> DOMAIN_ATTR_NESTING,/* two stages of translation */
> DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
> + DOMAIN_ATTR_SYS_CACHE,
I think you're trying to make this look generic, but it's really not.
If we need to funnel io-pgtable quirks through domain attributes, then I
think we should be open about that and add something like
DOMAIN_ATTR_IO_PGTABLE_CFG which could take a struct of page-table
configuration data for the domain (this could just be quirks initially,
but maybe it's worth extending to take ias, oas and page size)
Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv7 7/7] iommu: arm-smmu-impl: Add a space before open parenthesis
On Fri, Oct 30, 2020 at 02:53:14PM +0530, Sai Prakash Ranjan wrote:
> Fix the checkpatch warning for space required before the open
> parenthesis.
>
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> index ffaf3f91ba52..f16da4a21270 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> @@ -12,7 +12,7 @@
>
> static int arm_smmu_gr0_ns(int offset)
> {
> - switch(offset) {
> + switch (offset) {
> case ARM_SMMU_GR0_sCR0:
> case ARM_SMMU_GR0_sACR:
> case ARM_SMMU_GR0_sGFSR:
Whatever...
Acked-by: Will Deacon
Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv7 6/7] iommu: arm-smmu-impl: Use table to list QCOM implementations
On Fri, Oct 30, 2020 at 02:53:13PM +0530, Sai Prakash Ranjan wrote: > Use table and of_match_node() to match qcom implementation > instead of multiple of_device_compatible() calls for each > QCOM SMMU implementation. > > Signed-off-by: Sai Prakash Ranjan > --- > drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 9 + > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 - > drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 - > 3 files changed, 17 insertions(+), 14 deletions(-) Acked-by: Will Deacon Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
On Tue, Nov 10, 2020 at 06:50:32PM +0900, Tomasz Figa wrote: > In what terms it doesn't actually work? Last time I checked some > platforms actually defined CONFIG_DMA_NONCOHERENT, so those would > instead use the kmalloc() + dma_map() path. I don't have any > background on why that was added and whether it needs to be preserved, > though. Kieran, Laurent, do you have any insight? CONFIG_DMA_NONCOHERENT is set on sh and mips for platforms that may support non-coherent DMA at compile time (but at least for mips that doesn't actually means this gets used). Using that ifdef to decide on using usb_alloc_coherent vs letting the usb layer map the data seems at best odd, and if we are unlucky papering over a bug somewhere. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
On Tue, Nov 10, 2020 at 6:33 PM Ricardo Ribalda wrote: > > Hi Christoph > > On Tue, Nov 10, 2020 at 10:25 AM Christoph Hellwig wrote: > > > > On Mon, Nov 09, 2020 at 03:53:55PM +0100, Ricardo Ribalda wrote: > > > Hi Christoph > > > > > > I have started now to give a try to your patchset. Sorry for the delay. > > > > > > For uvc I have prepared this patch: > > > https://github.com/ribalda/linux/commit/9094fe223fe38f8c8ff21366d893b43cbbdf0113 > > > > > > I have tested successfully in a x86_64 noteboot..., yes I know there > > > is no change for that platform :). > > > I am trying to get hold of an arm device that can run the latest > > > kernel from upstream. > > > > > > On the meanwhile if you could take a look to the patch to verify that > > > this the way that you expect the drivers to use your api I would > > > appreciate it > > > > This looks pretty reaosnable. > > > > Great > Thanks Christoph for taking a look quickly. > Also FYI, I managed to boot an ARM device with that tree. But I could > not test the uvc driver (it was a remote device with no usb device > attached) > > Hopefully I will be able to test it for real this week. > > Any suggestions for how to measure performance difference? Back in time Kieran (+CC) shared a patch to add extra statistics for packet processing and payload assembly, with results of various approaches summarized in a spreadsheet: https://docs.google.com/spreadsheets/d/1uPdbdVcebO9OQ0LQ8hR2LGIEySWgSnGwwhzv7LPXAlU/edit#gid=0 That and just simple CPU usage comparison would be enough. > > Thanks! > > > Note that ifdef CONFIG_DMA_NONCOHERENT in the old code doesn't actually > > work, as that option is an internal thing just for mips and sh.. In what terms it doesn't actually work? Last time I checked some platforms actually defined CONFIG_DMA_NONCOHERENT, so those would instead use the kmalloc() + dma_map() path. I don't have any background on why that was added and whether it needs to be preserved, though. Kieran, Laurent, do you have any insight? Best regards, Tomasz ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
On Tue, Nov 10, 2020 at 10:33:05AM +0100, Ricardo Ribalda wrote: > Also FYI, I managed to boot an ARM device with that tree. But I could > not test the uvc driver (it was a remote device with no usb device > attached) > > Hopefully I will be able to test it for real this week. > > Any suggestions for how to measure performance difference? I have to admit I don't know at all how uvc works. But the main problem with dma_alloc_coherent is that all access is uncached. So anything that does larger and/or many data transfers to and from it will be glacially slow. With the dma streaming API we still have to pay for cache flushes, but only before and after the transfers, and in many cases in a somewhat optimized fashion. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
Hi Christoph On Tue, Nov 10, 2020 at 10:25 AM Christoph Hellwig wrote: > > On Mon, Nov 09, 2020 at 03:53:55PM +0100, Ricardo Ribalda wrote: > > Hi Christoph > > > > I have started now to give a try to your patchset. Sorry for the delay. > > > > For uvc I have prepared this patch: > > https://github.com/ribalda/linux/commit/9094fe223fe38f8c8ff21366d893b43cbbdf0113 > > > > I have tested successfully in a x86_64 noteboot..., yes I know there > > is no change for that platform :). > > I am trying to get hold of an arm device that can run the latest > > kernel from upstream. > > > > On the meanwhile if you could take a look to the patch to verify that > > this the way that you expect the drivers to use your api I would > > appreciate it > > This looks pretty reaosnable. > Great Also FYI, I managed to boot an ARM device with that tree. But I could not test the uvc driver (it was a remote device with no usb device attached) Hopefully I will be able to test it for real this week. Any suggestions for how to measure performance difference? Thanks! > Note that ifdef CONFIG_DMA_NONCOHERENT in the old code doesn't actually > work, as that option is an internal thing just for mips and sh.. -- Ricardo Ribalda ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
On Mon, Nov 09, 2020 at 03:53:55PM +0100, Ricardo Ribalda wrote: > Hi Christoph > > I have started now to give a try to your patchset. Sorry for the delay. > > For uvc I have prepared this patch: > https://github.com/ribalda/linux/commit/9094fe223fe38f8c8ff21366d893b43cbbdf0113 > > I have tested successfully in a x86_64 noteboot..., yes I know there > is no change for that platform :). > I am trying to get hold of an arm device that can run the latest > kernel from upstream. > > On the meanwhile if you could take a look to the patch to verify that > this the way that you expect the drivers to use your api I would > appreciate it This looks pretty reaosnable. Note that ifdef CONFIG_DMA_NONCOHERENT in the old code doesn't actually work, as that option is an internal thing just for mips and sh.. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH for-5.10] swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single
On Wed, Nov 04, 2020 at 09:04:38AM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 03, 2020 at 10:46:43AM +0100, Christoph Hellwig wrote: > > ping? > > Hopefully this goes through. I am in the process of testing it but ran > into testing issues that I believe are unrelated. Did you manage to make any progress? This fixes an issue with the new support for systems with DMA offsets in 5.10.. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers
On Tue, 2020-11-10 at 01:31 -0500, Qian Cai wrote:
> On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote:
> > From: Thomas Gleixner
> >
> > 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
> > the trigger type (edge/level) and the active low/high configuration. While
> > there are defines for initializing these variables and struct members, they
> > are not used consequently and the meaning of 'trigger' and 'polarity' is
> > opaque and confusing at best.
> >
> > Rename them to 'is_level' and 'active_low' and make them boolean in various
> > structs so it's entirely clear what the meaning is.
> >
> > Signed-off-by: Thomas Gleixner
> > Signed-off-by: David Woodhouse
> > ---
> > arch/x86/include/asm/hw_irq.h | 6 +-
> > arch/x86/kernel/apic/io_apic.c | 244 +---
> > arch/x86/pci/intel_mid_pci.c| 8 +-
> > drivers/iommu/amd/iommu.c | 10 +-
> > drivers/iommu/intel/irq_remapping.c | 9 +-
> > 5 files changed, 130 insertions(+), 147 deletions(-)
>
> Reverting the rest of patchset up to this commit on next-20201109 fixed an
> endless soft-lockups issue booting an AMD server below. I noticed that the
> failed boots always has this IOMMU IO_PAGE_FAULT before those soft-lockups:
Hm, attempting to reproduce this shows something else. Ever since
commit be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-
iommu api") in 5.5 the following stops working for me:
$ qemu-system-x86_64 -serial mon:stdio -kernel bzImage -machine
q35,accel=kvm,kernel-irqchip=split -m 2G -device amd-iommu,intremap=off -append
"console=ttyS0 apic=verbose debug" -display none
It hasn't got a hard drive but I can watch the SATA interrupts fail as
it probes the CD-ROM:
[7.403327] ata3.00: qc timeout (cmd 0xa1)
[7.405980] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Adding 'iommu=off' to the kernel command line makes it work again, in
that it correctly panics at the lack of a root file system, quickly.
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/2] dma-mapping: add benchmark support for streaming DMA APIs
On 10/11/2020 08:10, Song Bao Hua (Barry Song) wrote: Hello Robin, Christoph, Any further comment? John suggested that "depends on DEBUG_FS" should be added in Kconfig. I am collecting more comments to send v4 together with fixing this minor issue :-) Thanks Barry -Original Message- From: Song Bao Hua (Barry Song) Sent: Monday, November 2, 2020 9:07 PM To: iommu@lists.linux-foundation.org; h...@lst.de; robin.mur...@arm.com; m.szyprow...@samsung.com Cc: Linuxarm ; linux-kselft...@vger.kernel.org; xuwei (O) ; Song Bao Hua (Barry Song) ; Joerg Roedel ; Will Deacon ; Shuah Khan Subject: [PATCH v3 1/2] dma-mapping: add benchmark support for streaming DMA APIs Nowadays, there are increasing requirements to benchmark the performance of dma_map and dma_unmap particually while the device is attached to an IOMMU. This patch enables the support. Users can run specified number of threads to do dma_map_page and dma_unmap_page on a specific NUMA node with the specified duration. Then dma_map_benchmark will calculate the average latency for map and unmap. A difficulity for this benchmark is that dma_map/unmap APIs must run on a particular device. Each device might have different backend of IOMMU or non-IOMMU. So we use the driver_override to bind dma_map_benchmark to a particual device by: For platform devices: echo dma_map_benchmark > /sys/bus/platform/devices/xxx/driver_override echo xxx > /sys/bus/platform/drivers/xxx/unbind echo xxx > /sys/bus/platform/drivers/dma_map_benchmark/bind Hi Barry, For PCI devices: echo dma_map_benchmark > /sys/bus/pci/devices/:00:01.0/driver_override echo :00:01.0 > /sys/bus/pci/drivers/xxx/unbind echo :00:01.0 > /sys/bus/pci/drivers/dma_map_benchmark/bind Do we need to check if the device to which we attach actually has DMA mapping capability? Cc: Joerg Roedel Cc: Will Deacon Cc: Shuah Khan Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Signed-off-by: Barry Song --- Thanks, John ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v3 1/2] dma-mapping: add benchmark support for streaming DMA APIs
Hello Robin, Christoph,
Any further comment? John suggested that "depends on DEBUG_FS" should be added
in Kconfig.
I am collecting more comments to send v4 together with fixing this minor issue
:-)
Thanks
Barry
> -Original Message-
> From: Song Bao Hua (Barry Song)
> Sent: Monday, November 2, 2020 9:07 PM
> To: iommu@lists.linux-foundation.org; h...@lst.de; robin.mur...@arm.com;
> m.szyprow...@samsung.com
> Cc: Linuxarm ; linux-kselft...@vger.kernel.org; xuwei
> (O) ; Song Bao Hua (Barry Song)
> ; Joerg Roedel ; Will Deacon
> ; Shuah Khan
> Subject: [PATCH v3 1/2] dma-mapping: add benchmark support for streaming
> DMA APIs
>
> Nowadays, there are increasing requirements to benchmark the performance
> of dma_map and dma_unmap particually while the device is attached to an
> IOMMU.
>
> This patch enables the support. Users can run specified number of threads to
> do dma_map_page and dma_unmap_page on a specific NUMA node with the
> specified duration. Then dma_map_benchmark will calculate the average
> latency for map and unmap.
>
> A difficulity for this benchmark is that dma_map/unmap APIs must run on a
> particular device. Each device might have different backend of IOMMU or
> non-IOMMU.
>
> So we use the driver_override to bind dma_map_benchmark to a particual
> device by:
> For platform devices:
> echo dma_map_benchmark > /sys/bus/platform/devices/xxx/driver_override
> echo xxx > /sys/bus/platform/drivers/xxx/unbind
> echo xxx > /sys/bus/platform/drivers/dma_map_benchmark/bind
>
> For PCI devices:
> echo dma_map_benchmark >
> /sys/bus/pci/devices/:00:01.0/driver_override
> echo :00:01.0 > /sys/bus/pci/drivers/xxx/unbind echo :00:01.0 >
> /sys/bus/pci/drivers/dma_map_benchmark/bind
>
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Shuah Khan
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Signed-off-by: Barry Song
> ---
> -v3:
> * fix build issues reported by 0day kernel test robot
> -v2:
> * add PCI support; v1 supported platform devices only
> * replace ssleep by msleep_interruptible() to permit users to exit
> benchmark before it is completed
> * many changes according to Robin's suggestions, thanks! Robin
> - add standard deviation output to reflect the worst case
> - check users' parameters strictly like the number of threads
> - make cache dirty before dma_map
> - fix unpaired dma_map_page and dma_unmap_single;
> - remove redundant "long long" before ktime_to_ns();
> - use devm_add_action()
>
> kernel/dma/Kconfig | 8 +
> kernel/dma/Makefile| 1 +
> kernel/dma/map_benchmark.c | 296
> +
> 3 files changed, 305 insertions(+)
> create mode 100644 kernel/dma/map_benchmark.c
>
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index
> c99de4a21458..949c53da5991 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -225,3 +225,11 @@ config DMA_API_DEBUG_SG
> is technically out-of-spec.
>
> If unsure, say N.
> +
> +config DMA_MAP_BENCHMARK
> + bool "Enable benchmarking of streaming DMA mapping"
> + help
> + Provides /sys/kernel/debug/dma_map_benchmark that helps with
> testing
> + performance of dma_(un)map_page.
> +
> + See tools/testing/selftests/dma/dma_map_benchmark.c
> diff --git a/kernel/dma/Makefile b/kernel/dma/Makefile index
> dc755ab68aab..7aa6b26b1348 100644
> --- a/kernel/dma/Makefile
> +++ b/kernel/dma/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_DMA_API_DEBUG) += debug.o
> obj-$(CONFIG_SWIOTLB)+= swiotlb.o
> obj-$(CONFIG_DMA_COHERENT_POOL) += pool.o
> obj-$(CONFIG_DMA_REMAP) += remap.o
> +obj-$(CONFIG_DMA_MAP_BENCHMARK) += map_benchmark.o
> diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c
> new file mode 100644 index ..dc4e5ff48a2d
> --- /dev/null
> +++ b/kernel/dma/map_benchmark.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Hisilicon Limited.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DMA_MAP_BENCHMARK_IOWR('d', 1, struct map_benchmark)
> +#define DMA_MAP_MAX_THREADS 1024
> +#define DMA_MAP_MAX_SECONDS 300
> +
> +struct map_benchmark {
> + __u64 avg_map_100ns; /* average map latency in 100ns */
> + __u64 map_stddev; /* standard deviation of map latency */
> + __u64 avg_unmap_100ns; /* as above */
> + __u64 unmap_stddev;
> + __u32 threads; /* how many threads will do map/unmap in parallel */
> + __u32 seconds; /* how long the test will last */
> + int node; /* which numa node this benchmark will run on */
> + __u64 expansion[10];/* For future use */
> +};
> +
> +struct map_benchmark_data {
> + st
