All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Cc: "jroedel-l3A5Bk7waGM@public.gmane.org"
	<jroedel-l3A5Bk7waGM@public.gmane.org>,
	Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH 10/22] iommu: Introduce direct mapped region handling
Date: Thu, 11 Jun 2015 20:22:44 +0100	[thread overview]
Message-ID: <5579E004.5080904@arm.com> (raw)
In-Reply-To: <1432831305-11126-11-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>

On 28/05/15 17:41, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
>
> Add two new functions to the IOMMU-API to allow the IOMMU
> drivers to export the requirements for direct mapped regions
> per device.
> This is useful for exporting the information in Intel VT-d's
> RMRR entries or AMD-Vi's unity mappings.

Whilst I agree with the utility of a common abstraction for the IOMMU 
core to use (I think we could easily turn Marek's proposal for ARM[1] 
into a generic of_iommu_ backend for this), I'm less convinced that it 
needs to be exported as part of the API.

I was envisioning eventually moving the IOVA data inside the 
iommu_domain itself for the managed DMA-API implementation, so that the 
IOMMU core would be responsible for setting it up. Then the core just 
needs to ask the driver about any relevant reservations as it creates a 
domain/attaches a device, and the callers can remain in blissful 
ignorance. Besides, beyond probe time, I don't see many good reasons at 
all for a caller to have a struct device for something, yet not have 
taken control of any DMA the firmware left running.

Is that at odds with your ideas?

Robin.

[1]:http://article.gmane.org/gmane.linux.kernel.samsung-soc/45429

> Signed-off-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
> ---
>   drivers/iommu/iommu.c | 16 ++++++++++++++++
>   include/linux/iommu.h | 31 +++++++++++++++++++++++++++++++
>   2 files changed, 47 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a0a38bd..6b8d6e7 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1469,3 +1469,19 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
> +
> +void iommu_get_dm_regions(struct device *dev, struct list_head *list)
> +{
> +	const struct iommu_ops *ops = dev->bus->iommu_ops;
> +
> +	if (ops && ops->get_dm_regions)
> +		ops->get_dm_regions(dev, list);
> +}
> +
> +void iommu_put_dm_regions(struct device *dev, struct list_head *list)
> +{
> +	const struct iommu_ops *ops = dev->bus->iommu_ops;
> +
> +	if (ops && ops->put_dm_regions)
> +		ops->put_dm_regions(dev, list);
> +}
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 683a1c4..6894999 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -114,6 +114,20 @@ enum iommu_attr {
>   	DOMAIN_ATTR_MAX,
>   };
>
> +/**
> + * struct iommu_dm_region - descriptor for a direct mapped memory region
> + * @list: Linked list pointers
> + * @start: System physical start address of the region
> + * @length: Length of the region in bytes
> + * @prot: IOMMU Protection flags (READ/WRITE/...)
> + */
> +struct iommu_dm_region {
> +	struct list_head	list;
> +	phys_addr_t		start;
> +	size_t			length;
> +	int			prot;
> +};
> +
>   #ifdef CONFIG_IOMMU_API
>
>   /**
> @@ -159,6 +173,10 @@ struct iommu_ops {
>   	int (*domain_set_attr)(struct iommu_domain *domain,
>   			       enum iommu_attr attr, void *data);
>
> +	/* Request/Free a list of direct mapping requirements for a device */
> +	void (*get_dm_regions)(struct device *dev, struct list_head *list);
> +	void (*put_dm_regions)(struct device *dev, struct list_head *list);
> +
>   	/* Window handling functions */
>   	int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
>   				    phys_addr_t paddr, u64 size, int prot);
> @@ -205,6 +223,9 @@ extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t io
>   extern void iommu_set_fault_handler(struct iommu_domain *domain,
>   			iommu_fault_handler_t handler, void *token);
>
> +extern void iommu_get_dm_regions(struct device *dev, struct list_head *list);
> +extern void iommu_put_dm_regions(struct device *dev, struct list_head *list);
> +
>   extern int iommu_attach_group(struct iommu_domain *domain,
>   			      struct iommu_group *group);
>   extern void iommu_detach_group(struct iommu_domain *domain,
> @@ -379,6 +400,16 @@ static inline void iommu_set_fault_handler(struct iommu_domain *domain,
>   {
>   }
>
> +static inline void iommu_get_dm_regions(struct device *dev,
> +					struct list_head *list)
> +{
> +}
> +
> +static inline void iommu_put_dm_regions(struct device *dev,
> +					struct list_head *list)
> +{
> +}
> +
>   static inline int iommu_attach_group(struct iommu_domain *domain,
>   				     struct iommu_group *group)
>   {
>

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Joerg Roedel <joro@8bytes.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Cc: Will Deacon <Will.Deacon@arm.com>, 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>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Oded Gabbay <oded.gabbay@gmail.com>,
	"jroedel@suse.de" <jroedel@suse.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 10/22] iommu: Introduce direct mapped region handling
Date: Thu, 11 Jun 2015 20:22:44 +0100	[thread overview]
Message-ID: <5579E004.5080904@arm.com> (raw)
In-Reply-To: <1432831305-11126-11-git-send-email-joro@8bytes.org>

On 28/05/15 17:41, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> Add two new functions to the IOMMU-API to allow the IOMMU
> drivers to export the requirements for direct mapped regions
> per device.
> This is useful for exporting the information in Intel VT-d's
> RMRR entries or AMD-Vi's unity mappings.

Whilst I agree with the utility of a common abstraction for the IOMMU 
core to use (I think we could easily turn Marek's proposal for ARM[1] 
into a generic of_iommu_ backend for this), I'm less convinced that it 
needs to be exported as part of the API.

I was envisioning eventually moving the IOVA data inside the 
iommu_domain itself for the managed DMA-API implementation, so that the 
IOMMU core would be responsible for setting it up. Then the core just 
needs to ask the driver about any relevant reservations as it creates a 
domain/attaches a device, and the callers can remain in blissful 
ignorance. Besides, beyond probe time, I don't see many good reasons at 
all for a caller to have a struct device for something, yet not have 
taken control of any DMA the firmware left running.

Is that at odds with your ideas?

Robin.

[1]:http://article.gmane.org/gmane.linux.kernel.samsung-soc/45429

> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>   drivers/iommu/iommu.c | 16 ++++++++++++++++
>   include/linux/iommu.h | 31 +++++++++++++++++++++++++++++++
>   2 files changed, 47 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a0a38bd..6b8d6e7 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1469,3 +1469,19 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
> +
> +void iommu_get_dm_regions(struct device *dev, struct list_head *list)
> +{
> +	const struct iommu_ops *ops = dev->bus->iommu_ops;
> +
> +	if (ops && ops->get_dm_regions)
> +		ops->get_dm_regions(dev, list);
> +}
> +
> +void iommu_put_dm_regions(struct device *dev, struct list_head *list)
> +{
> +	const struct iommu_ops *ops = dev->bus->iommu_ops;
> +
> +	if (ops && ops->put_dm_regions)
> +		ops->put_dm_regions(dev, list);
> +}
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 683a1c4..6894999 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -114,6 +114,20 @@ enum iommu_attr {
>   	DOMAIN_ATTR_MAX,
>   };
>
> +/**
> + * struct iommu_dm_region - descriptor for a direct mapped memory region
> + * @list: Linked list pointers
> + * @start: System physical start address of the region
> + * @length: Length of the region in bytes
> + * @prot: IOMMU Protection flags (READ/WRITE/...)
> + */
> +struct iommu_dm_region {
> +	struct list_head	list;
> +	phys_addr_t		start;
> +	size_t			length;
> +	int			prot;
> +};
> +
>   #ifdef CONFIG_IOMMU_API
>
>   /**
> @@ -159,6 +173,10 @@ struct iommu_ops {
>   	int (*domain_set_attr)(struct iommu_domain *domain,
>   			       enum iommu_attr attr, void *data);
>
> +	/* Request/Free a list of direct mapping requirements for a device */
> +	void (*get_dm_regions)(struct device *dev, struct list_head *list);
> +	void (*put_dm_regions)(struct device *dev, struct list_head *list);
> +
>   	/* Window handling functions */
>   	int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
>   				    phys_addr_t paddr, u64 size, int prot);
> @@ -205,6 +223,9 @@ extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t io
>   extern void iommu_set_fault_handler(struct iommu_domain *domain,
>   			iommu_fault_handler_t handler, void *token);
>
> +extern void iommu_get_dm_regions(struct device *dev, struct list_head *list);
> +extern void iommu_put_dm_regions(struct device *dev, struct list_head *list);
> +
>   extern int iommu_attach_group(struct iommu_domain *domain,
>   			      struct iommu_group *group);
>   extern void iommu_detach_group(struct iommu_domain *domain,
> @@ -379,6 +400,16 @@ static inline void iommu_set_fault_handler(struct iommu_domain *domain,
>   {
>   }
>
> +static inline void iommu_get_dm_regions(struct device *dev,
> +					struct list_head *list)
> +{
> +}
> +
> +static inline void iommu_put_dm_regions(struct device *dev,
> +					struct list_head *list)
> +{
> +}
> +
>   static inline int iommu_attach_group(struct iommu_domain *domain,
>   				     struct iommu_group *group)
>   {
>


  parent reply	other threads:[~2015-06-11 19:22 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 16:41 [PATCH 00/22 v2] Introduce default domains for iommu groups Joerg Roedel
2015-05-28 16:41 ` Joerg Roedel
     [not found] ` <1432831305-11126-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-05-28 16:41   ` [PATCH 01/22] iommu: Remove function name from pr_fmt() Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 02/22] iommu: Add a few printk messages to group handling code Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 03/22] iommu: Propagate error in add_iommu_group Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
     [not found]     ` <1432831305-11126-4-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-29  9:28       ` Heiko Stübner
2015-06-29  9:28         ` Heiko Stübner
2015-06-29  9:37         ` Joerg Roedel
2015-06-29  9:37           ` Joerg Roedel
2015-06-29 14:06         ` Joerg Roedel
2015-06-29 14:06           ` Joerg Roedel
     [not found]           ` <20150629140637.GK18569-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-29 19:55             ` Heiko Stübner
2015-06-29 19:55               ` Heiko Stübner
2015-05-28 16:41   ` [PATCH 04/22] iommu: Clean up after a failed bus initialization Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 05/22] iommu: Call remove_device call-back after driver release Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 06/22] iommu: Allocate a default domain for iommu groups Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
     [not found]     ` <1432831305-11126-7-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-11 17:33       ` Robin Murphy
2015-06-11 17:33         ` Robin Murphy
2015-06-11 17:33       ` Robin Murphy
2015-06-11 17:33         ` Robin Murphy
2015-05-28 16:41   ` [PATCH 07/22] iommu: Limit iommu_attach/detach_device to devices with their own group Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 08/22] iommu: Make sure a device is always attached to a domain Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
     [not found]     ` <1432831305-11126-9-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-11 17:41       ` Robin Murphy
2015-06-11 17:41         ` Robin Murphy
2015-05-28 16:41   ` [PATCH 09/22] iommu: Add iommu_get_domain_for_dev function Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 10/22] iommu: Introduce direct mapped region handling Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
     [not found]     ` <1432831305-11126-11-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-05 14:17       ` Will Deacon
2015-06-05 14:17         ` Will Deacon
     [not found]         ` <20150605141749.GA7420-5wv7dgnIgG8@public.gmane.org>
2015-06-05 14:32           ` jroedel-l3A5Bk7waGM
2015-06-05 14:32             ` jroedel
2015-06-11 19:22       ` Robin Murphy [this message]
2015-06-11 19:22         ` Robin Murphy
2015-05-28 16:41   ` [PATCH 11/22] iommu: Create direct mappings in default domains Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 12/22] iommu: Add function to query the default domain of a group Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 13/22] iommu: Introduce iommu_request_dm_for_dev() Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 14/22] iommu/amd: Implement dm_region call-backs Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 15/22] iommu/amd: Use default domain if available for DMA-API Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 16/22] iommu/amd: Implement add_device and remove_device Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 17/22] iommu/amd: Support IOMMU_DOMAIN_DMA type allocation Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 18/22] iommu/amd: Support IOMMU_DOMAIN_IDENTITY " Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 19/22] iommu/amd: Put IOMMUv2 devices in a direct mapped domain Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 20/22] iommu/amd: Get rid of device_dma_ops_init() Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 21/22] iommu/amd: Remove unused fields from struct dma_ops_domain Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-05-28 16:41   ` [PATCH 22/22] iommu/amd: Propagate errors from amd_iommu_init_api Joerg Roedel
2015-05-28 16:41     ` Joerg Roedel
2015-06-05 14:22   ` [PATCH 00/22 v2] Introduce default domains for iommu groups Will Deacon
2015-06-05 14:22     ` Will Deacon
2015-06-05 14:35     ` jroedel

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=5579E004.5080904@arm.com \
    --to=robin.murphy-5wv7dgnigg8@public.gmane.org \
    --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
    --cc=jroedel-l3A5Bk7waGM@public.gmane.org \
    --cc=kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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 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.