From: Joerg Roedel <joerg.roedel@amd.com>
To: KyongHo Cho <pullip.cho@samsung.com>
Cc: Joerg Roedel <joro@8bytes.org>,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org,
Younglak Kim <younglak1004.kim@samsung.com>,
Subash Patel <subash.ramaswamy@linaro.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Sanghyun Lee <sanghyun75.lee@samsung.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
Date: Wed, 25 Jan 2012 12:44:17 +0100 [thread overview]
Message-ID: <20120125114417.GE19255@amd.com> (raw)
In-Reply-To: <CAHQjnOMyoOH2cFjjGSzMvefZTQGROmQgaA8S0MmxnKGHWyQhyA@mail.gmail.com>
On Wed, Jan 25, 2012 at 03:51:58PM +0900, KyongHo Cho wrote:
> > This isn't really a problem. We allow destroying a domain with devices
> > attached. So this WARN_ON is not necessary.
> >
> BTW, Isn't it a problem when a device driver does not know that its
> iommu domain is destroyed?
> Can we regards that it is the faulty use of iommu API?
Yes we could, but we don't ;) The domain_destroy path has to take care
of this anyway to be robust, so we can also take away the need to unattach
everything from a domain from the iommu-api user.
> > This looks like you are partially re-implementing behavior of generic
> > code because you are mapping multiple sections at once. The generic map
> > code already splits up the address range correctly, so no need to do
> > this in the driver (unless there is some benefit in the hardware, like
> > an IOTLB entry that can cover multiple sections or something similar).
> >
> Yes, I wanted to avoid repeated function call by iommu_map().
> s5p_iommu_map() maps once for the same page size since it is efficient
> and simple.
> That's why this driver initializes domain->pgsize_bitmap with 0xFFFFF000
> even though our IOMMU driver just supports 3 different page sizes
> including 4KB, 64KB and 1MB.
Repeated function calls are not a real performance problem in the
iommu-code in my experience. The overhead is usualle somewhere else.
> Do you think it is better for s5p_iommu_map() to map just one page at once?
In general I think we should not duplicate code. This logic was moved to
the generic part for a reason and iommu drivers should use it unless
there is a very good reason not to do so.
>
> >> +static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >> + unsigned long iova, size_t size)
> >> +{
> >> + struct exynos_iommu_domain *priv = domain->priv;
> >> + struct iommu_client *client;
> >> + unsigned long flags;
> >> +
> >> + BUG_ON(priv->pgtable == NULL);
> >> +
> >> + spin_lock_irqsave(&priv->pgtablelock, flags);
> >> +
> >> + while (size != 0) {
> >> + int i, nent, order;
> >> + unsigned long *pent, *sent;
> >
> > Same with this while-loop. This looks like it re-implements behavior
> > from the generic code.
> >
> If a region to unmap consists of tens of pages
> there is no way to avoid flushing IOTLB repeatedly.
>
> Out iommu driver doesn't need to flush IOTLB more than once for a
> region to unmap.
>
> Do you think the driver is better to unmaps just one page at once
> though flushing IOTLB repeatedly?
Is I/O-TLB flushing an expensive operation?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
WARNING: multiple messages have this Message-ID (diff)
From: joerg.roedel@amd.com (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
Date: Wed, 25 Jan 2012 12:44:17 +0100 [thread overview]
Message-ID: <20120125114417.GE19255@amd.com> (raw)
In-Reply-To: <CAHQjnOMyoOH2cFjjGSzMvefZTQGROmQgaA8S0MmxnKGHWyQhyA@mail.gmail.com>
On Wed, Jan 25, 2012 at 03:51:58PM +0900, KyongHo Cho wrote:
> > This isn't really a problem. We allow destroying a domain with devices
> > attached. So this WARN_ON is not necessary.
> >
> BTW, Isn't it a problem when a device driver does not know that its
> iommu domain is destroyed?
> Can we regards that it is the faulty use of iommu API?
Yes we could, but we don't ;) The domain_destroy path has to take care
of this anyway to be robust, so we can also take away the need to unattach
everything from a domain from the iommu-api user.
> > This looks like you are partially re-implementing behavior of generic
> > code because you are mapping multiple sections at once. The generic map
> > code already splits up the address range correctly, so no need to do
> > this in the driver (unless there is some benefit in the hardware, like
> > an IOTLB entry that can cover multiple sections or something similar).
> >
> Yes, I wanted to avoid repeated function call by iommu_map().
> s5p_iommu_map() maps once for the same page size since it is efficient
> and simple.
> That's why this driver initializes domain->pgsize_bitmap with 0xFFFFF000
> even though our IOMMU driver just supports 3 different page sizes
> including 4KB, 64KB and 1MB.
Repeated function calls are not a real performance problem in the
iommu-code in my experience. The overhead is usualle somewhere else.
> Do you think it is better for s5p_iommu_map() to map just one page at once?
In general I think we should not duplicate code. This logic was moved to
the generic part for a reason and iommu drivers should use it unless
there is a very good reason not to do so.
>
> >> +static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?unsigned long iova, size_t size)
> >> +{
> >> + ? ? struct exynos_iommu_domain *priv = domain->priv;
> >> + ? ? struct iommu_client *client;
> >> + ? ? unsigned long flags;
> >> +
> >> + ? ? BUG_ON(priv->pgtable == NULL);
> >> +
> >> + ? ? spin_lock_irqsave(&priv->pgtablelock, flags);
> >> +
> >> + ? ? while (size != 0) {
> >> + ? ? ? ? ? ? int i, nent, order;
> >> + ? ? ? ? ? ? unsigned long *pent, *sent;
> >
> > Same with this while-loop. This looks like it re-implements behavior
> > from the generic code.
> >
> If a region to unmap consists of tens of pages
> there is no way to avoid flushing IOTLB repeatedly.
>
> Out iommu driver doesn't need to flush IOTLB more than once for a
> region to unmap.
>
> Do you think the driver is better to unmaps just one page at once
> though flushing IOTLB repeatedly?
Is I/O-TLB flushing an expensive operation?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joerg.roedel@amd.com>
To: KyongHo Cho <pullip.cho@samsung.com>
Cc: Joerg Roedel <joro@8bytes.org>,
<linux-samsung-soc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<iommu@lists.linux-foundation.org>,
Younglak Kim <younglak1004.kim@samsung.com>,
Subash Patel <subash.ramaswamy@linaro.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Sanghyun Lee <sanghyun75.lee@samsung.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
Date: Wed, 25 Jan 2012 12:44:17 +0100 [thread overview]
Message-ID: <20120125114417.GE19255@amd.com> (raw)
In-Reply-To: <CAHQjnOMyoOH2cFjjGSzMvefZTQGROmQgaA8S0MmxnKGHWyQhyA@mail.gmail.com>
On Wed, Jan 25, 2012 at 03:51:58PM +0900, KyongHo Cho wrote:
> > This isn't really a problem. We allow destroying a domain with devices
> > attached. So this WARN_ON is not necessary.
> >
> BTW, Isn't it a problem when a device driver does not know that its
> iommu domain is destroyed?
> Can we regards that it is the faulty use of iommu API?
Yes we could, but we don't ;) The domain_destroy path has to take care
of this anyway to be robust, so we can also take away the need to unattach
everything from a domain from the iommu-api user.
> > This looks like you are partially re-implementing behavior of generic
> > code because you are mapping multiple sections at once. The generic map
> > code already splits up the address range correctly, so no need to do
> > this in the driver (unless there is some benefit in the hardware, like
> > an IOTLB entry that can cover multiple sections or something similar).
> >
> Yes, I wanted to avoid repeated function call by iommu_map().
> s5p_iommu_map() maps once for the same page size since it is efficient
> and simple.
> That's why this driver initializes domain->pgsize_bitmap with 0xFFFFF000
> even though our IOMMU driver just supports 3 different page sizes
> including 4KB, 64KB and 1MB.
Repeated function calls are not a real performance problem in the
iommu-code in my experience. The overhead is usualle somewhere else.
> Do you think it is better for s5p_iommu_map() to map just one page at once?
In general I think we should not duplicate code. This logic was moved to
the generic part for a reason and iommu drivers should use it unless
there is a very good reason not to do so.
>
> >> +static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >> + unsigned long iova, size_t size)
> >> +{
> >> + struct exynos_iommu_domain *priv = domain->priv;
> >> + struct iommu_client *client;
> >> + unsigned long flags;
> >> +
> >> + BUG_ON(priv->pgtable == NULL);
> >> +
> >> + spin_lock_irqsave(&priv->pgtablelock, flags);
> >> +
> >> + while (size != 0) {
> >> + int i, nent, order;
> >> + unsigned long *pent, *sent;
> >
> > Same with this while-loop. This looks like it re-implements behavior
> > from the generic code.
> >
> If a region to unmap consists of tens of pages
> there is no way to avoid flushing IOTLB repeatedly.
>
> Out iommu driver doesn't need to flush IOTLB more than once for a
> region to unmap.
>
> Do you think the driver is better to unmaps just one page at once
> though flushing IOTLB repeatedly?
Is I/O-TLB flushing an expensive operation?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2012-01-25 11:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 12:26 [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms KyongHo Cho
2011-12-29 12:26 ` KyongHo Cho
2011-12-29 12:26 ` KyongHo Cho
2012-01-23 14:27 ` 'Joerg Roedel'
2012-01-23 14:27 ` 'Joerg Roedel'
2012-01-25 6:51 ` KyongHo Cho
2012-01-25 6:51 ` KyongHo Cho
2012-01-25 11:44 ` Joerg Roedel [this message]
2012-01-25 11:44 ` Joerg Roedel
2012-01-25 11:44 ` Joerg Roedel
2012-01-27 2:13 ` Kukjin Kim
2012-01-27 2:13 ` Kukjin Kim
2012-01-30 10:34 ` KyongHo Cho
2012-01-30 10:34 ` KyongHo Cho
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=20120125114417.GE19255@amd.com \
--to=joerg.roedel@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=pullip.cho@samsung.com \
--cc=sanghyun75.lee@samsung.com \
--cc=subash.ramaswamy@linaro.org \
--cc=younglak1004.kim@samsung.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.