From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Cc: "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org"
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"arnd-r2nGTMty4D4@public.gmane.org"
<arnd-r2nGTMty4D4@public.gmane.org>,
"stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org"
<stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
"thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org"
<thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org"
<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [RFC PATCH 3/5] iommu: implement common IOMMU ops for DMA mapping
Date: Fri, 23 Jan 2015 18:14:03 +0000 [thread overview]
Message-ID: <54C28F6B.4020707@arm.com> (raw)
In-Reply-To: <54C287F7.3060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Laura,
Thanks for looking
On 23/01/15 17:42, Laura Abbott wrote:
> On 1/12/2015 12:48 PM, Robin Murphy wrote:
>> Taking inspiration from the existing arch/arm code, break out some
>> generic functions to interface the DMA-API to the IOMMU-API. This will
>> do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
>>
>> Whilst the target is arm64, rather than introduce yet another private
>> implementation, place this in common code as the first step towards
>> consolidating the numerous versions spread around between architecture
>> code and IOMMU drivers.
>>
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> ---
>> include/linux/dma-iommu.h | 78 ++++++++
>> lib/Kconfig | 8 +
>> lib/Makefile | 1 +
>> lib/dma-iommu.c | 455 ++++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 542 insertions(+)
>> create mode 100644 include/linux/dma-iommu.h
>> create mode 100644 lib/dma-iommu.c
>>
>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>> new file mode 100644
>> index 0000000..4515407
>> --- /dev/null
>> +++ b/include/linux/dma-iommu.h
> <snip>
>> +
>> +struct iommu_dma_mapping *iommu_dma_create_mapping(struct iommu_ops *ops,
>> + dma_addr_t base, size_t size)
>> +{
>> + struct iommu_dma_mapping *mapping;
>> + struct iommu_domain *domain;
>> + struct iova_domain *iovad;
>> + struct iommu_domain_geometry *dg;
>> + unsigned long order, base_pfn, end_pfn;
>> +
>> + pr_debug("base=%pad\tsize=0x%zx\n", &base, size);
>> + mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
>> + if (!mapping)
>> + return NULL;
>> +
>> + /*
>> + * HACK: We'd like to ask the relevant IOMMU in ops for a suitable
>> + * domain, but until that happens, bypass the bus nonsense and create
>> + * one directly for this specific device/IOMMU combination...
>> + */
>> + domain = kzalloc(sizeof(*domain), GFP_KERNEL);
>> +
>> + if (!domain)
>> + goto out_free_mapping;
>> + domain->ops = ops;
>> +
>> + if (ops->domain_init(domain))
>> + goto out_free_mapping;
>> + /*
>> + * ...and do the bare minimum to sanity-check that the domain allows
>> + * at least some access to the device...
>> + */
>> + dg = &domain->geometry;
>> + if (!(base < dg->aperture_end && base + size > dg->aperture_start)) {
>> + pr_warn("DMA range outside IOMMU capability; is DT correct?\n");
>> + goto out_free_mapping;
>> + }
>
> This check seems to always fail with base = 0 because dg->aperture_end is
> always going to be 0 as well. base <= dg->aperature_end ?
>
Strictly you're right, since aperture_end should be the highest mappable
address thus you could create a valid, if a little silly, 1-byte domain
if both were zero. However, it shouldn't really be zero.
I put this bit in since the majority of IOMMU drivers set up the
geometry in domain_init and it seemed worth making use of. The ARM SMMU
driver is currently one of the odd ones out that don't, however one of
my as-yet-unpublished patches porting it to the new of_iommu_configure
framework involves fixing domain initialisation and adds geometry setup
as well - that's what I've been testing with. I'm hoping to get that
series out soon, but among other things it needs a messy merge with
Will's pagetable changes.
Robin.
next prev parent reply other threads:[~2015-01-23 18:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 20:48 [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Robin Murphy
[not found] ` <cover.1421086706.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2015-01-12 20:48 ` [RFC PATCH 1/5] arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 2/5] arm64: implement generic IOMMU configuration Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 3/5] iommu: implement common IOMMU ops for DMA mapping Robin Murphy
[not found] ` <09e5515a9afcb3235f4c425520cd18a6032d31b4.1421086706.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2015-01-23 17:42 ` Laura Abbott
[not found] ` <54C287F7.3060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-01-23 18:14 ` Robin Murphy [this message]
2015-01-27 0:21 ` Joerg Roedel
[not found] ` <20150127002116.GI30345-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-01-27 12:27 ` Robin Murphy
[not found] ` <54C7843B.3000605-5wv7dgnIgG8@public.gmane.org>
2015-01-27 12:38 ` Joerg Roedel
[not found] ` <20150127123809.GJ30345-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-01-28 13:53 ` Will Deacon
2015-01-12 20:48 ` [RFC PATCH 4/5] arm64: add IOMMU dma_ops Robin Murphy
[not found] ` <aa7de3b1dd189c31eb8b14d0c0eea699183f8a2c.1421086706.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2015-01-23 15:26 ` Will Deacon
[not found] ` <20150123152605.GA31460-5wv7dgnIgG8@public.gmane.org>
2015-01-23 17:33 ` Robin Murphy
2015-01-26 3:25 ` Joseph Lo
[not found] ` <54C5B3B9.1040300-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-01-27 17:30 ` Robin Murphy
2015-01-26 9:10 ` Joseph Lo
2015-01-28 2:22 ` Joseph Lo
2015-03-05 14:31 ` Marek Szyprowski
2015-01-12 20:48 ` [RFC PATCH 5/5] arm64: hook up " Robin Murphy
2015-01-13 11:08 ` [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Stefano Stabellini
[not found] ` <alpine.DEB.2.02.1501131102540.3058-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>
2015-01-13 11:45 ` Robin Murphy
2015-01-23 16:47 ` Catalin Marinas
[not found] ` <20150123164759.GF9557-M2fw3Uu6cmfZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2015-01-23 17:41 ` Robin Murphy
2015-03-05 14:31 ` Marek Szyprowski
[not found] ` <54F868A8.7070103-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-03-05 16:42 ` Robin Murphy
2015-01-13 8:02 ` Yingjoe Chen
2015-01-13 12:07 ` Robin Murphy
2015-01-15 18:35 ` Robin Murphy
2015-01-16 7:21 ` Yong Wu
2015-01-16 20:12 ` 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=54C28F6B.4020707@arm.com \
--to=robin.murphy-5wv7dgnigg8@public.gmane.org \
--cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org \
--cc=thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox