From: Will Deacon <will.deacon@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, thunder.leizhen@huawei.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com,
guohanjun@huawei.com, huawei.libin@huawei.com,
john.garry@huawei.com
Subject: Re: [PATCH v7 2/6] iommu/dma: Add support for non-strict mode
Date: Tue, 18 Sep 2018 18:10:07 +0100 [thread overview]
Message-ID: <20180918171007.GJ16498@arm.com> (raw)
In-Reply-To: <0a891cec4bb164f8cf2f57c753791a7d1f5f1d81.1536935328.git.robin.murphy@arm.com>
Hi Robin,
On Fri, Sep 14, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
> From: Zhen Lei <thunder.leizhen@huawei.com>
>
> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
> capable call domain->ops->flush_iotlb_all to flush TLB.
> 2. During the iommu domain initialization phase, base on domain->non_strict
> field to check whether non-strict mode is supported or not. If so, call
> init_iova_flush_queue to register iovad->flush_cb callback.
> 3. All unmap(contains iova-free) APIs will finally invoke __iommu_dma_unmap
> -->iommu_dma_free_iova. If the domain is non-strict, call queue_iova to
> put off iova freeing, and omit iommu_tlb_sync operation.
Hmm, this is basically just a commentary on the code. Please could you write
it more in terms of the problem that's being solved?
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> [rm: convert raw boolean to domain attribute]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 29 ++++++++++++++++++++++++++++-
> include/linux/iommu.h | 1 +
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 511ff9a1d6d9..092e6926dc3c 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -55,6 +55,9 @@ struct iommu_dma_cookie {
> };
> struct list_head msi_page_list;
> spinlock_t msi_lock;
> +
> + /* Only be assigned in non-strict mode, otherwise it's NULL */
> + struct iommu_domain *domain;
> };
>
> static inline size_t cookie_msi_granule(struct iommu_dma_cookie *cookie)
> @@ -257,6 +260,17 @@ static int iova_reserve_iommu_regions(struct device *dev,
> return ret;
> }
>
> +static void iommu_dma_flush_iotlb_all(struct iova_domain *iovad)
> +{
> + struct iommu_dma_cookie *cookie;
> + struct iommu_domain *domain;
> +
> + cookie = container_of(iovad, struct iommu_dma_cookie, iovad);
> + domain = cookie->domain;
> +
> + domain->ops->flush_iotlb_all(domain);
Can we rely on this function pointer being non-NULL? I think it would
be better to call iommu_flush_tlb_all(cookie->domain) instead.
> +}
> +
> /**
> * iommu_dma_init_domain - Initialise a DMA mapping domain
> * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> @@ -275,6 +289,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
> + int attr = 1;
Do we actually need to initialise this?
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 2/6] iommu/dma: Add support for non-strict mode
Date: Tue, 18 Sep 2018 18:10:07 +0100 [thread overview]
Message-ID: <20180918171007.GJ16498@arm.com> (raw)
In-Reply-To: <0a891cec4bb164f8cf2f57c753791a7d1f5f1d81.1536935328.git.robin.murphy@arm.com>
Hi Robin,
On Fri, Sep 14, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
> From: Zhen Lei <thunder.leizhen@huawei.com>
>
> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
> capable call domain->ops->flush_iotlb_all to flush TLB.
> 2. During the iommu domain initialization phase, base on domain->non_strict
> field to check whether non-strict mode is supported or not. If so, call
> init_iova_flush_queue to register iovad->flush_cb callback.
> 3. All unmap(contains iova-free) APIs will finally invoke __iommu_dma_unmap
> -->iommu_dma_free_iova. If the domain is non-strict, call queue_iova to
> put off iova freeing, and omit iommu_tlb_sync operation.
Hmm, this is basically just a commentary on the code. Please could you write
it more in terms of the problem that's being solved?
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> [rm: convert raw boolean to domain attribute]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 29 ++++++++++++++++++++++++++++-
> include/linux/iommu.h | 1 +
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 511ff9a1d6d9..092e6926dc3c 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -55,6 +55,9 @@ struct iommu_dma_cookie {
> };
> struct list_head msi_page_list;
> spinlock_t msi_lock;
> +
> + /* Only be assigned in non-strict mode, otherwise it's NULL */
> + struct iommu_domain *domain;
> };
>
> static inline size_t cookie_msi_granule(struct iommu_dma_cookie *cookie)
> @@ -257,6 +260,17 @@ static int iova_reserve_iommu_regions(struct device *dev,
> return ret;
> }
>
> +static void iommu_dma_flush_iotlb_all(struct iova_domain *iovad)
> +{
> + struct iommu_dma_cookie *cookie;
> + struct iommu_domain *domain;
> +
> + cookie = container_of(iovad, struct iommu_dma_cookie, iovad);
> + domain = cookie->domain;
> +
> + domain->ops->flush_iotlb_all(domain);
Can we rely on this function pointer being non-NULL? I think it would
be better to call iommu_flush_tlb_all(cookie->domain) instead.
> +}
> +
> /**
> * iommu_dma_init_domain - Initialise a DMA mapping domain
> * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> @@ -275,6 +289,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
> + int attr = 1;
Do we actually need to initialise this?
Will
next prev parent reply other threads:[~2018-09-18 17:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 14:30 [PATCH v7 0/6] Add non-strict mode support for iommu-dma Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 1/6] iommu/arm-smmu-v3: Implement flush_iotlb_all hook Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 2/6] iommu/dma: Add support for non-strict mode Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-18 17:10 ` Will Deacon [this message]
2018-09-18 17:10 ` Will Deacon
[not found] ` <20180918171007.GJ16498-5wv7dgnIgG8@public.gmane.org>
2018-09-18 18:52 ` Robin Murphy
2018-09-18 18:52 ` Robin Murphy
2018-09-18 18:52 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 3/6] iommu/io-pgtable-arm: " Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 4/6] iommu: Add bootup option "iommu.non_strict" Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 17:10 ` Will Deacon
2018-09-18 19:01 ` Robin Murphy
2018-09-18 19:01 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 5/6] iommu/arm-smmu-v3: Add support for non-strict mode Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 17:10 ` Will Deacon
2018-09-18 19:09 ` Robin Murphy
2018-09-18 19:09 ` Robin Murphy
2018-09-14 14:30 ` [PATCH v7 6/6] iommu/arm-smmu: Support " Robin Murphy
2018-09-14 14:30 ` Robin Murphy
2018-09-18 17:10 ` Will Deacon
2018-09-18 17:10 ` Will Deacon
2018-09-18 19:22 ` Robin Murphy
2018-09-18 19:22 ` Robin Murphy
2018-09-18 17:10 ` [PATCH v7 0/6] Add non-strict mode support for iommu-dma Will Deacon
2018-09-18 17:10 ` Will Deacon
2018-09-18 18:28 ` Robin Murphy
2018-09-18 18:28 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180918171007.GJ16498@arm.com \
--to=will.deacon@arm.com \
--cc=guohanjun@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.com \
--cc=thunder.leizhen@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.