All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, robin.murphy@arm.com,
	alex.williamson@redhat.com, will.deacon@arm.com,
	tglx@linutronix.de, jason@lakedaemon.net,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	drjones@redhat.com, linux-kernel@vger.kernel.org,
	pranav.sawargaonkar@gmail.com, iommu@lists.linux-foundation.org,
	punit.agrawal@arm.com, diana.craciun@nxp.com
Subject: Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
Date: Thu, 10 Nov 2016 16:46:06 +0100	[thread overview]
Message-ID: <20161110154606.GH2078@8bytes.org> (raw)
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>

On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
> 
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> 
> ---
> 
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
>  drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>  
>  #define FSYNR0_WNR			(1 << 4)
>  
> +#define MSI_IOVA_BASE			0x8000000
> +#define MSI_IOVA_LENGTH			0x100000
> +
>  static int force_stage;
>  module_param(force_stage, int, S_IRUGO);
>  MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>  	return iommu_fwspec_add_ids(dev, &fwid, 1);
>  }
>  
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> +					   struct pci_dev *dev)
> +{
> +	struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> +	struct iommu_reserved_region *region;
> +	struct resource_entry *window;
> +	phys_addr_t start;
> +	size_t length;
> +
> +	resource_list_for_each_entry(window, &bridge->windows) {
> +		if (resource_type(window->res) != IORESOURCE_MEM &&
> +		    resource_type(window->res) != IORESOURCE_IO)
> +			continue;

Why do you care about IO resources?

> +
> +		start = window->res->start - window->offset;
> +		length = window->res->end - window->res->start + 1;
> +
> +		iommu_reserved_region_for_each(region, domain) {
> +			if (region->start == start && region->length == length)
> +				continue;
> +		}
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = start;
> +		region->length = length;
> +
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +	}
> +	return 0;
> +}
> +
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> +					 struct device *device)
> +{
> +	struct iommu_reserved_region *region;
> +	int ret = 0;
> +
> +	/* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> +	if (!domain->iova_cookie) {
> +
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = MSI_IOVA_BASE;
> +		region->length = MSI_IOVA_LENGTH;
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +
> +		ret = iommu_get_dma_msi_region_cookie(domain,
> +						region->start, region->length);
> +		if (ret)
> +			return ret;

Gah, I hate this. Is there no other and simpler way to get the MSI
region than allocating an iova-domain? In that regard, I also _hate_ the
patch before introducing this weird iommu_get_dma_msi_region_cookie()
function.

Allocation an iova-domain is pretty expensive, as it also includes
per-cpu data-structures and all, so please don't do this just for the
purpose of compiling a list of reserved regions.



	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	marc.zyngier-5wv7dgnIgG8@public.gmane.org,
	punit.agrawal-5wv7dgnIgG8@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
	christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
Date: Thu, 10 Nov 2016 16:46:06 +0100	[thread overview]
Message-ID: <20161110154606.GH2078@8bytes.org> (raw)
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
> 
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
> 
> Signed-off-by: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> 
> ---
> 
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
>  drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>  
>  #define FSYNR0_WNR			(1 << 4)
>  
> +#define MSI_IOVA_BASE			0x8000000
> +#define MSI_IOVA_LENGTH			0x100000
> +
>  static int force_stage;
>  module_param(force_stage, int, S_IRUGO);
>  MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>  	return iommu_fwspec_add_ids(dev, &fwid, 1);
>  }
>  
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> +					   struct pci_dev *dev)
> +{
> +	struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> +	struct iommu_reserved_region *region;
> +	struct resource_entry *window;
> +	phys_addr_t start;
> +	size_t length;
> +
> +	resource_list_for_each_entry(window, &bridge->windows) {
> +		if (resource_type(window->res) != IORESOURCE_MEM &&
> +		    resource_type(window->res) != IORESOURCE_IO)
> +			continue;

Why do you care about IO resources?

> +
> +		start = window->res->start - window->offset;
> +		length = window->res->end - window->res->start + 1;
> +
> +		iommu_reserved_region_for_each(region, domain) {
> +			if (region->start == start && region->length == length)
> +				continue;
> +		}
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = start;
> +		region->length = length;
> +
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +	}
> +	return 0;
> +}
> +
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> +					 struct device *device)
> +{
> +	struct iommu_reserved_region *region;
> +	int ret = 0;
> +
> +	/* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> +	if (!domain->iova_cookie) {
> +
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = MSI_IOVA_BASE;
> +		region->length = MSI_IOVA_LENGTH;
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +
> +		ret = iommu_get_dma_msi_region_cookie(domain,
> +						region->start, region->length);
> +		if (ret)
> +			return ret;

Gah, I hate this. Is there no other and simpler way to get the MSI
region than allocating an iova-domain? In that regard, I also _hate_ the
patch before introducing this weird iommu_get_dma_msi_region_cookie()
function.

Allocation an iova-domain is pretty expensive, as it also includes
per-cpu data-structures and all, so please don't do this just for the
purpose of compiling a list of reserved regions.



	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
Date: Thu, 10 Nov 2016 16:46:06 +0100	[thread overview]
Message-ID: <20161110154606.GH2078@8bytes.org> (raw)
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>

On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
> 
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> 
> ---
> 
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
>  drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>  
>  #define FSYNR0_WNR			(1 << 4)
>  
> +#define MSI_IOVA_BASE			0x8000000
> +#define MSI_IOVA_LENGTH			0x100000
> +
>  static int force_stage;
>  module_param(force_stage, int, S_IRUGO);
>  MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>  	return iommu_fwspec_add_ids(dev, &fwid, 1);
>  }
>  
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> +					   struct pci_dev *dev)
> +{
> +	struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> +	struct iommu_reserved_region *region;
> +	struct resource_entry *window;
> +	phys_addr_t start;
> +	size_t length;
> +
> +	resource_list_for_each_entry(window, &bridge->windows) {
> +		if (resource_type(window->res) != IORESOURCE_MEM &&
> +		    resource_type(window->res) != IORESOURCE_IO)
> +			continue;

Why do you care about IO resources?

> +
> +		start = window->res->start - window->offset;
> +		length = window->res->end - window->res->start + 1;
> +
> +		iommu_reserved_region_for_each(region, domain) {
> +			if (region->start == start && region->length == length)
> +				continue;
> +		}
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = start;
> +		region->length = length;
> +
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +	}
> +	return 0;
> +}
> +
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> +					 struct device *device)
> +{
> +	struct iommu_reserved_region *region;
> +	int ret = 0;
> +
> +	/* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> +	if (!domain->iova_cookie) {
> +
> +		region = kzalloc(sizeof(*region), GFP_KERNEL);
> +		if (!region)
> +			return -ENOMEM;
> +
> +		region->start = MSI_IOVA_BASE;
> +		region->length = MSI_IOVA_LENGTH;
> +		list_add_tail(&region->list, &domain->reserved_regions);
> +
> +		ret = iommu_get_dma_msi_region_cookie(domain,
> +						region->start, region->length);
> +		if (ret)
> +			return ret;

Gah, I hate this. Is there no other and simpler way to get the MSI
region than allocating an iova-domain? In that regard, I also _hate_ the
patch before introducing this weird iommu_get_dma_msi_region_cookie()
function.

Allocation an iova-domain is pretty expensive, as it also includes
per-cpu data-structures and all, so please don't do this just for the
purpose of compiling a list of reserved regions.



	Joerg

  parent reply	other threads:[~2016-11-10 15:46 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 11:23 [RFC v2 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 - Alt II Eric Auger
2016-11-04 11:23 ` Eric Auger
2016-11-04 11:23 ` Eric Auger
2016-11-04 11:23 ` [RFC v2 1/8] vfio: fix vfio_info_cap_add/shift Eric Auger
2016-11-04 11:23   ` Eric Auger
2016-11-04 11:24 ` [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range Eric Auger
2016-11-04 11:24   ` Eric Auger
2016-11-10 15:22   ` Joerg Roedel
2016-11-10 15:22     ` Joerg Roedel
2016-11-10 15:22     ` Joerg Roedel
2016-11-10 15:41     ` Auger Eric
2016-11-10 15:41       ` Auger Eric
2016-11-04 11:24 ` [RFC v2 3/8] iommu/dma: Allow MSI-only cookies Eric Auger
2016-11-14 12:36   ` Robin Murphy
2016-11-14 12:36     ` Robin Murphy
2016-11-14 12:36     ` Robin Murphy
2016-11-14 23:23     ` Auger Eric
2016-11-14 23:23       ` Auger Eric
2016-11-14 23:23       ` Auger Eric
2016-11-15 14:52       ` Robin Murphy
2016-11-15 14:52         ` Robin Murphy
2016-11-04 11:24 ` [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain Eric Auger
2016-11-04 11:24   ` Eric Auger
2016-11-04 14:00   ` Robin Murphy
2016-11-04 14:00     ` Robin Murphy
2016-11-04 14:00     ` Robin Murphy
2016-11-10 11:22     ` Auger Eric
2016-11-10 11:22       ` Auger Eric
2016-11-10 11:54       ` Robin Murphy
2016-11-10 11:54         ` Robin Murphy
2016-11-10 12:14         ` Auger Eric
2016-11-10 12:14           ` Auger Eric
2016-11-10 12:48           ` Robin Murphy
2016-11-10 12:48             ` Robin Murphy
2016-11-10 12:48             ` Robin Murphy
2016-11-10 15:37   ` Joerg Roedel
2016-11-10 15:37     ` Joerg Roedel
2016-11-10 15:37     ` Joerg Roedel
2016-11-10 15:42     ` Auger Eric
2016-11-10 15:42       ` Auger Eric
2016-11-04 11:24 ` [RFC v2 5/8] vfio/type1: Introduce RESV_IOVA_RANGE capability Eric Auger
2016-11-04 11:24   ` Eric Auger
2016-11-04 11:24 ` [RFC v2 6/8] iommu: Handle the list of reserved regions Eric Auger
2016-11-04 11:24 ` [RFC v2 7/8] iommu/vt-d: Implement add_reserved_regions callback Eric Auger
2016-11-04 11:24   ` Eric Auger
2016-11-04 11:24 ` [RFC v2 8/8] iommu/arm-smmu: implement " Eric Auger
2016-11-04 11:24   ` Eric Auger
2016-11-04 14:16   ` Robin Murphy
2016-11-04 14:16     ` Robin Murphy
2016-11-10 15:46   ` Joerg Roedel [this message]
2016-11-10 15:46     ` Joerg Roedel
2016-11-10 15:46     ` Joerg Roedel
2016-11-10 15:57     ` Auger Eric
2016-11-10 15:57       ` Auger Eric
2016-11-10 15:57       ` Auger Eric
2016-11-10 16:13       ` Joerg Roedel
2016-11-10 16:13         ` Joerg Roedel
2016-11-10 18:00         ` Auger Eric
2016-11-10 18:00           ` Auger Eric
2016-11-10 18:00           ` Auger Eric
2016-11-11 11:42           ` Joerg Roedel
2016-11-11 11:42             ` Joerg Roedel
2016-11-11 11:42             ` Joerg Roedel
2016-11-11 15:47             ` Auger Eric
2016-11-11 15:47               ` Auger Eric
2016-11-11 16:22               ` Joerg Roedel
2016-11-11 16:22                 ` Joerg Roedel
2016-11-11 16:45                 ` Auger Eric
2016-11-11 16:45                   ` Auger Eric
2016-11-11 16:45                   ` Auger Eric
2016-11-14 15:31                   ` Joerg Roedel
2016-11-14 15:31                     ` Joerg Roedel
2016-11-14 16:08                     ` Auger Eric
2016-11-14 16:08                       ` Auger Eric
2016-11-14 16:20                       ` Joerg Roedel
2016-11-14 16:20                         ` Joerg Roedel
2016-11-14 16:20                         ` Joerg Roedel
2016-11-14 16:57                         ` Auger Eric
2016-11-14 16:57                           ` Auger Eric
2016-11-10 16:07     ` Robin Murphy
2016-11-10 16:07       ` Robin Murphy
2016-11-10 16:07       ` Robin Murphy
2016-11-10 16:16       ` Joerg Roedel
2016-11-10 16:16         ` Joerg Roedel
2016-11-10 16:16         ` Joerg Roedel
2016-11-11 14:34         ` Robin Murphy
2016-11-11 14:34           ` Robin Murphy
2016-11-11 14:34           ` Robin Murphy
2016-11-11 15:03           ` Joerg Roedel
2016-11-11 15:03             ` Joerg Roedel
2016-11-11 15:03             ` 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=20161110154606.GH2078@8bytes.org \
    --to=joro@8bytes.org \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=diana.craciun@nxp.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jason@lakedaemon.net \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=pranav.sawargaonkar@gmail.com \
    --cc=punit.agrawal@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.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.