LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>, Kukjin Kim <kgene@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Heiko Stuebner <heiko@sntech.de>, Hiroshi Doyu <hdoyu@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"jroedel@suse.de" <jroedel@suse.de>
Subject: Re: [PATCH 2/5] iommu: Allocate a default domain for iommu groups
Date: Wed, 28 Jan 2015 15:11:03 +0000	[thread overview]
Message-ID: <54C8FC07.2050003@arm.com> (raw)
In-Reply-To: <20150128143006.GQ1569@arm.com>

On 28/01/15 14:30, Will Deacon wrote:
> On Tue, Jan 27, 2015 at 12:08:56AM +0000, Joerg Roedel wrote:
>> From: Joerg Roedel <jroedel@suse.de>
>>
>> The default domain will be used (if supported by the iommu
>> driver) when the devices in the iommu group are not attached
>> to any other domain.
>>
>> Signed-off-by: Joerg Roedel <jroedel@suse.de>
>> ---
>>   drivers/iommu/iommu.c | 26 +++++++++++++++++++++++---
>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 34636eb..8f33ddd3 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -76,6 +76,9 @@ struct iommu_group_attribute iommu_group_attr_##_name =		\
>>   #define to_iommu_group(_kobj)		\
>>   	container_of(_kobj, struct iommu_group, kobj)
>>
>> +static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>> +						 enum iommu_domain_type type);
>> +
>>   static ssize_t iommu_group_attr_show(struct kobject *kobj,
>>   				     struct attribute *__attr, char *buf)
>>   {
>> @@ -362,6 +365,17 @@ rename:
>>
>>   	kobject_get(group->devices_kobj);
>>
>> +	/*
>> +	 * Try to allocate a default domain for the group, if this
>> +	 * hasn't happened yet. This is not the best place to do that,
>> +	 * it should happen in iommu_group_alloc(). But we have no
>> +	 * iommu_ops there yet, so the allocation has to happen here for
>> +	 * now.
>> +	 */
>> +	if (group->default_domain == NULL)
>> +		group->default_domain = __iommu_domain_alloc(dev->bus,
>> +							     IOMMU_DOMAIN_DMA);
>
> Having a per-group domain is wasteful for IOMMUs that only support a modest
> number of concurrent domains, so in reality I think we need to have one
> domain per IOMMU instance. Is that possible?

Strictly speaking, it is, provided you can identify instances (I've 
hacked up such a thing controlled from the DMA mapping side), but 
there's a question of how to handle devices with differing DMA ranges. 
The Intel IOVA allocator could actually handle them sharing one address 
space, since you can perform individual allocations with different 
constraints, but I'm not sure if that really makes sense. Perhaps one 
domain per dma-ranges variation per instance?

> One problem with the current per-bus approach is that __iommu_domain_alloc
> can't figure out which IOMMU instance corresponds to the group.

Indeed - I think it might make sense to pass devices around instead of 
buses, and for now stick in an abstraction like:

static const struct iommu_ops *get_iommu_for_dev(struct device *dev)
{
	return dev->bus->iommu_ops;
}

in which we can then later hook up some sort of of_iommu_get_ops-based 
lookup for non-PCI devices. Which ends up more or less looking like 
Thierry's original idea, but kept private to the IOMMU API internals.

Robin.


  reply	other threads:[~2015-01-28 22:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27  0:08 [RFC PATCH 0/5] iommu: Introduce default domains " Joerg Roedel
2015-01-27  0:08 ` [PATCH 1/5] iommu: Add default domain to iommu-groups Joerg Roedel
2015-01-27  0:08 ` [PATCH 2/5] iommu: Allocate a default domain for iommu groups Joerg Roedel
2015-01-28 14:30   ` Will Deacon
2015-01-28 15:11     ` Robin Murphy [this message]
2015-01-30 12:25     ` Joerg Roedel
2015-01-27  0:08 ` [PATCH 3/5] iommu: Limit iommu_attach/detach_device to devices with their own group Joerg Roedel
2015-01-28 14:35   ` Will Deacon
2015-01-30 12:28     ` Joerg Roedel
2015-02-02 16:45       ` Will Deacon
2015-02-03 12:25   ` Thierry Reding
2015-02-03 12:59     ` Joerg Roedel
2015-01-27  0:08 ` [PATCH 4/5] iommu: Make sure a device is always attached to a domain Joerg Roedel
2015-01-28 14:38   ` Will Deacon
2015-01-30 12:29     ` Joerg Roedel
2015-01-27  0:08 ` [PATCH 5/5] iommu: Add iommu_get_domain_for_dev function Joerg Roedel

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=54C8FC07.2050003@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=arnd@arndb.de \
    --cc=dwmw2@infradead.org \
    --cc=hdoyu@nvidia.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=kgene@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=will.deacon@arm.com \
    --subject='Re: [PATCH 2/5] iommu: Allocate a default domain for iommu groups' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).