All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	rjw@rjwysocki.net, lenb@kernel.org, joro@8bytes.org,
	mst@redhat.com
Cc: will@kernel.org, catalin.marinas@arm.com,
	baolu.lu@linux.intel.com, dwmw2@infradead.org,
	linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,
	virtualization@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org, eric.auger@redhat.com,
	sebastien.boeuf@intel.com, kevin.tian@intel.com,
	lorenzo.pieralisi@arm.com, guohanjun@huawei.com,
	sudeep.holla@arm.com
Subject: Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()
Date: Wed, 16 Jun 2021 18:02:39 +0100	[thread overview]
Message-ID: <6ce5fecb-fc81-5bf1-3577-6a09437b243e@arm.com> (raw)
In-Reply-To: <20210610075130.67517-6-jean-philippe@linaro.org>

On 2021-06-10 08:51, Jean-Philippe Brucker wrote:
> dma-iommu uses the address bounds described in domain->geometry during
> IOVA allocation. The address size parameters of iommu_setup_dma_ops()
> are useful for describing additional limits set by the platform
> firmware, but aren't needed for drivers that call this function from
> probe_finalize(). The base parameter can be zero because dma-iommu
> already removes the first IOVA page, and the limit parameter can be
> U64_MAX because it's only checked against the domain geometry. Simplify
> calls to iommu_setup_dma_ops().
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>   drivers/iommu/amd/iommu.c   |  9 +--------
>   drivers/iommu/dma-iommu.c   |  4 +++-
>   drivers/iommu/intel/iommu.c | 10 +---------
>   3 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 94b96d81fcfd..d3123bc05c08 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -1708,14 +1708,7 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
>   
>   static void amd_iommu_probe_finalize(struct device *dev)
>   {
> -	struct iommu_domain *domain;
> -
> -	/* Domains are initialized for this device - have a look what we ended up with */
> -	domain = iommu_get_domain_for_dev(dev);
> -	if (domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void amd_iommu_release_device(struct device *dev)
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c62e19bed302..175f8eaeb5b3 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1322,7 +1322,9 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>   	if (domain->type == IOMMU_DOMAIN_DMA) {
>   		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
>   			goto out_err;
> -		dev->dma_ops = &iommu_dma_ops;
> +		set_dma_ops(dev, &iommu_dma_ops);
> +	} else {
> +		set_dma_ops(dev, NULL);

I'm not keen on moving this here, since iommu-dma only knows that its 
own ops are right for devices it *is* managing; it can't assume any 
particular ops are appropriate for devices it isn't. The idea here is 
that arch_setup_dma_ops() may have already set the appropriate ops for 
the non-IOMMU case, so if the default domain type is passthrough then we 
leave those in place.

For example, I do still plan to revisit my conversion of arch/arm 
someday, at which point I'd have to undo this for that reason.

Simplifying the base and size arguments is of course fine, but TBH I'd 
say rip the whole bloody lot out of the arch_setup_dma_ops() flow now. 
It's a considerable faff passing them around for nothing but a tenuous 
sanity check in iommu_dma_init_domain(), and now that dev->dma_range_map 
is a common thing we should expect that to give us any relevant 
limitations if we even still care.

That said, those are all things which can be fixed up later if the 
series is otherwise ready to go and there's still a chance of landing it 
for 5.14. If you do have any other reason to respin, then I think the 
x86 probe_finalize functions simply want an unconditional 
set_dma_ops(dev, NULL) before the iommu_setup_dma_ops() call.

Cheers,
Robin.

>   	}
>   
>   	return;
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 85f18342603c..8d866940692a 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5165,15 +5165,7 @@ static void intel_iommu_release_device(struct device *dev)
>   
>   static void intel_iommu_probe_finalize(struct device *dev)
>   {
> -	dma_addr_t base = IOVA_START_PFN << VTD_PAGE_SHIFT;
> -	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> -	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> -
> -	if (domain && domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, base,
> -				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void intel_iommu_get_resv_regions(struct device *device,
> 

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	rjw@rjwysocki.net, lenb@kernel.org, joro@8bytes.org,
	mst@redhat.com
Cc: kevin.tian@intel.com, catalin.marinas@arm.com,
	sudeep.holla@arm.com, virtualization@lists.linux-foundation.org,
	linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,
	sebastien.boeuf@intel.com, guohanjun@huawei.com, will@kernel.org,
	dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()
Date: Wed, 16 Jun 2021 18:02:39 +0100	[thread overview]
Message-ID: <6ce5fecb-fc81-5bf1-3577-6a09437b243e@arm.com> (raw)
In-Reply-To: <20210610075130.67517-6-jean-philippe@linaro.org>

On 2021-06-10 08:51, Jean-Philippe Brucker wrote:
> dma-iommu uses the address bounds described in domain->geometry during
> IOVA allocation. The address size parameters of iommu_setup_dma_ops()
> are useful for describing additional limits set by the platform
> firmware, but aren't needed for drivers that call this function from
> probe_finalize(). The base parameter can be zero because dma-iommu
> already removes the first IOVA page, and the limit parameter can be
> U64_MAX because it's only checked against the domain geometry. Simplify
> calls to iommu_setup_dma_ops().
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>   drivers/iommu/amd/iommu.c   |  9 +--------
>   drivers/iommu/dma-iommu.c   |  4 +++-
>   drivers/iommu/intel/iommu.c | 10 +---------
>   3 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 94b96d81fcfd..d3123bc05c08 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -1708,14 +1708,7 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
>   
>   static void amd_iommu_probe_finalize(struct device *dev)
>   {
> -	struct iommu_domain *domain;
> -
> -	/* Domains are initialized for this device - have a look what we ended up with */
> -	domain = iommu_get_domain_for_dev(dev);
> -	if (domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void amd_iommu_release_device(struct device *dev)
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c62e19bed302..175f8eaeb5b3 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1322,7 +1322,9 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>   	if (domain->type == IOMMU_DOMAIN_DMA) {
>   		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
>   			goto out_err;
> -		dev->dma_ops = &iommu_dma_ops;
> +		set_dma_ops(dev, &iommu_dma_ops);
> +	} else {
> +		set_dma_ops(dev, NULL);

I'm not keen on moving this here, since iommu-dma only knows that its 
own ops are right for devices it *is* managing; it can't assume any 
particular ops are appropriate for devices it isn't. The idea here is 
that arch_setup_dma_ops() may have already set the appropriate ops for 
the non-IOMMU case, so if the default domain type is passthrough then we 
leave those in place.

For example, I do still plan to revisit my conversion of arch/arm 
someday, at which point I'd have to undo this for that reason.

Simplifying the base and size arguments is of course fine, but TBH I'd 
say rip the whole bloody lot out of the arch_setup_dma_ops() flow now. 
It's a considerable faff passing them around for nothing but a tenuous 
sanity check in iommu_dma_init_domain(), and now that dev->dma_range_map 
is a common thing we should expect that to give us any relevant 
limitations if we even still care.

That said, those are all things which can be fixed up later if the 
series is otherwise ready to go and there's still a chance of landing it 
for 5.14. If you do have any other reason to respin, then I think the 
x86 probe_finalize functions simply want an unconditional 
set_dma_ops(dev, NULL) before the iommu_setup_dma_ops() call.

Cheers,
Robin.

>   	}
>   
>   	return;
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 85f18342603c..8d866940692a 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5165,15 +5165,7 @@ static void intel_iommu_release_device(struct device *dev)
>   
>   static void intel_iommu_probe_finalize(struct device *dev)
>   {
> -	dma_addr_t base = IOVA_START_PFN << VTD_PAGE_SHIFT;
> -	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> -	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> -
> -	if (domain && domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, base,
> -				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void intel_iommu_get_resv_regions(struct device *device,
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	rjw@rjwysocki.net, lenb@kernel.org, joro@8bytes.org,
	mst@redhat.com
Cc: lorenzo.pieralisi@arm.com, eric.auger@redhat.com,
	catalin.marinas@arm.com, sudeep.holla@arm.com,
	virtualization@lists.linux-foundation.org,
	linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,
	sebastien.boeuf@intel.com, guohanjun@huawei.com, will@kernel.org,
	dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org,
	baolu.lu@linux.intel.com
Subject: Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()
Date: Wed, 16 Jun 2021 18:02:39 +0100	[thread overview]
Message-ID: <6ce5fecb-fc81-5bf1-3577-6a09437b243e@arm.com> (raw)
In-Reply-To: <20210610075130.67517-6-jean-philippe@linaro.org>

On 2021-06-10 08:51, Jean-Philippe Brucker wrote:
> dma-iommu uses the address bounds described in domain->geometry during
> IOVA allocation. The address size parameters of iommu_setup_dma_ops()
> are useful for describing additional limits set by the platform
> firmware, but aren't needed for drivers that call this function from
> probe_finalize(). The base parameter can be zero because dma-iommu
> already removes the first IOVA page, and the limit parameter can be
> U64_MAX because it's only checked against the domain geometry. Simplify
> calls to iommu_setup_dma_ops().
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>   drivers/iommu/amd/iommu.c   |  9 +--------
>   drivers/iommu/dma-iommu.c   |  4 +++-
>   drivers/iommu/intel/iommu.c | 10 +---------
>   3 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 94b96d81fcfd..d3123bc05c08 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -1708,14 +1708,7 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
>   
>   static void amd_iommu_probe_finalize(struct device *dev)
>   {
> -	struct iommu_domain *domain;
> -
> -	/* Domains are initialized for this device - have a look what we ended up with */
> -	domain = iommu_get_domain_for_dev(dev);
> -	if (domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void amd_iommu_release_device(struct device *dev)
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c62e19bed302..175f8eaeb5b3 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1322,7 +1322,9 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>   	if (domain->type == IOMMU_DOMAIN_DMA) {
>   		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
>   			goto out_err;
> -		dev->dma_ops = &iommu_dma_ops;
> +		set_dma_ops(dev, &iommu_dma_ops);
> +	} else {
> +		set_dma_ops(dev, NULL);

I'm not keen on moving this here, since iommu-dma only knows that its 
own ops are right for devices it *is* managing; it can't assume any 
particular ops are appropriate for devices it isn't. The idea here is 
that arch_setup_dma_ops() may have already set the appropriate ops for 
the non-IOMMU case, so if the default domain type is passthrough then we 
leave those in place.

For example, I do still plan to revisit my conversion of arch/arm 
someday, at which point I'd have to undo this for that reason.

Simplifying the base and size arguments is of course fine, but TBH I'd 
say rip the whole bloody lot out of the arch_setup_dma_ops() flow now. 
It's a considerable faff passing them around for nothing but a tenuous 
sanity check in iommu_dma_init_domain(), and now that dev->dma_range_map 
is a common thing we should expect that to give us any relevant 
limitations if we even still care.

That said, those are all things which can be fixed up later if the 
series is otherwise ready to go and there's still a chance of landing it 
for 5.14. If you do have any other reason to respin, then I think the 
x86 probe_finalize functions simply want an unconditional 
set_dma_ops(dev, NULL) before the iommu_setup_dma_ops() call.

Cheers,
Robin.

>   	}
>   
>   	return;
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 85f18342603c..8d866940692a 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5165,15 +5165,7 @@ static void intel_iommu_release_device(struct device *dev)
>   
>   static void intel_iommu_probe_finalize(struct device *dev)
>   {
> -	dma_addr_t base = IOVA_START_PFN << VTD_PAGE_SHIFT;
> -	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> -	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> -
> -	if (domain && domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, base,
> -				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void intel_iommu_get_resv_regions(struct device *device,
> 
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	rjw@rjwysocki.net, lenb@kernel.org, joro@8bytes.org,
	mst@redhat.com
Cc: will@kernel.org, catalin.marinas@arm.com,
	baolu.lu@linux.intel.com, dwmw2@infradead.org,
	linux-acpi@vger.kernel.org, iommu@lists.linux-foundation.org,
	virtualization@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org, eric.auger@redhat.com,
	sebastien.boeuf@intel.com, kevin.tian@intel.com,
	lorenzo.pieralisi@arm.com, guohanjun@huawei.com,
	sudeep.holla@arm.com
Subject: Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()
Date: Wed, 16 Jun 2021 18:02:39 +0100	[thread overview]
Message-ID: <6ce5fecb-fc81-5bf1-3577-6a09437b243e@arm.com> (raw)
In-Reply-To: <20210610075130.67517-6-jean-philippe@linaro.org>

On 2021-06-10 08:51, Jean-Philippe Brucker wrote:
> dma-iommu uses the address bounds described in domain->geometry during
> IOVA allocation. The address size parameters of iommu_setup_dma_ops()
> are useful for describing additional limits set by the platform
> firmware, but aren't needed for drivers that call this function from
> probe_finalize(). The base parameter can be zero because dma-iommu
> already removes the first IOVA page, and the limit parameter can be
> U64_MAX because it's only checked against the domain geometry. Simplify
> calls to iommu_setup_dma_ops().
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>   drivers/iommu/amd/iommu.c   |  9 +--------
>   drivers/iommu/dma-iommu.c   |  4 +++-
>   drivers/iommu/intel/iommu.c | 10 +---------
>   3 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 94b96d81fcfd..d3123bc05c08 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -1708,14 +1708,7 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
>   
>   static void amd_iommu_probe_finalize(struct device *dev)
>   {
> -	struct iommu_domain *domain;
> -
> -	/* Domains are initialized for this device - have a look what we ended up with */
> -	domain = iommu_get_domain_for_dev(dev);
> -	if (domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void amd_iommu_release_device(struct device *dev)
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c62e19bed302..175f8eaeb5b3 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1322,7 +1322,9 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>   	if (domain->type == IOMMU_DOMAIN_DMA) {
>   		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
>   			goto out_err;
> -		dev->dma_ops = &iommu_dma_ops;
> +		set_dma_ops(dev, &iommu_dma_ops);
> +	} else {
> +		set_dma_ops(dev, NULL);

I'm not keen on moving this here, since iommu-dma only knows that its 
own ops are right for devices it *is* managing; it can't assume any 
particular ops are appropriate for devices it isn't. The idea here is 
that arch_setup_dma_ops() may have already set the appropriate ops for 
the non-IOMMU case, so if the default domain type is passthrough then we 
leave those in place.

For example, I do still plan to revisit my conversion of arch/arm 
someday, at which point I'd have to undo this for that reason.

Simplifying the base and size arguments is of course fine, but TBH I'd 
say rip the whole bloody lot out of the arch_setup_dma_ops() flow now. 
It's a considerable faff passing them around for nothing but a tenuous 
sanity check in iommu_dma_init_domain(), and now that dev->dma_range_map 
is a common thing we should expect that to give us any relevant 
limitations if we even still care.

That said, those are all things which can be fixed up later if the 
series is otherwise ready to go and there's still a chance of landing it 
for 5.14. If you do have any other reason to respin, then I think the 
x86 probe_finalize functions simply want an unconditional 
set_dma_ops(dev, NULL) before the iommu_setup_dma_ops() call.

Cheers,
Robin.

>   	}
>   
>   	return;
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 85f18342603c..8d866940692a 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5165,15 +5165,7 @@ static void intel_iommu_release_device(struct device *dev)
>   
>   static void intel_iommu_probe_finalize(struct device *dev)
>   {
> -	dma_addr_t base = IOVA_START_PFN << VTD_PAGE_SHIFT;
> -	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> -	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> -
> -	if (domain && domain->type == IOMMU_DOMAIN_DMA)
> -		iommu_setup_dma_ops(dev, base,
> -				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
> -	else
> -		set_dma_ops(dev, NULL);
> +	iommu_setup_dma_ops(dev, 0, U64_MAX);
>   }
>   
>   static void intel_iommu_get_resv_regions(struct device *device,
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-06-16 17:02 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10  7:51 [PATCH v4 0/6] Add support for ACPI VIOT Jean-Philippe Brucker
2021-06-10  7:51 ` Jean-Philippe Brucker
2021-06-10  7:51 ` Jean-Philippe Brucker
2021-06-10  7:51 ` Jean-Philippe Brucker
2021-06-10  7:51 ` [PATCH v4 1/6] ACPI: arm64: Move DMA setup operations out of IORT Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16  9:35   ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-10  7:51 ` [PATCH v4 2/6] ACPI: Move IOMMU setup code " Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16  9:35   ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-16  9:35     ` Eric Auger
2021-06-18  7:41     ` Jean-Philippe Brucker
2021-06-18  7:41       ` Jean-Philippe Brucker
2021-06-18  7:41       ` Jean-Philippe Brucker
2021-06-18  7:41       ` Jean-Philippe Brucker
2021-06-18  9:16       ` Robin Murphy
2021-06-18  9:16         ` Robin Murphy
2021-06-18  9:16         ` Robin Murphy
2021-06-18  9:16         ` Robin Murphy
2021-06-10  7:51 ` [PATCH v4 3/6] ACPI: Add driver for the VIOT table Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16 13:26   ` Eric Auger
2021-06-16 13:26     ` Eric Auger
2021-06-16 13:26     ` Eric Auger
2021-06-16 13:26     ` Eric Auger
2021-06-18  7:43     ` Jean-Philippe Brucker
2021-06-18  7:43       ` Jean-Philippe Brucker
2021-06-18  7:43       ` Jean-Philippe Brucker
2021-06-18  7:43       ` Jean-Philippe Brucker
2021-06-17 11:50   ` Rafael J. Wysocki
2021-06-17 11:50     ` Rafael J. Wysocki
2021-06-17 11:50     ` Rafael J. Wysocki
2021-06-17 11:50     ` Rafael J. Wysocki
2021-06-18  7:54     ` Jean-Philippe Brucker
2021-06-18  7:54       ` Jean-Philippe Brucker
2021-06-18  7:54       ` Jean-Philippe Brucker
2021-06-18  7:54       ` Jean-Philippe Brucker
2021-06-10  7:51 ` [PATCH v4 4/6] iommu/dma: Pass address limit rather than size to iommu_setup_dma_ops() Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16 15:28   ` Eric Auger
2021-06-16 15:28     ` Eric Auger
2021-06-16 15:28     ` Eric Auger
2021-06-16 15:28     ` Eric Auger
2021-06-18  9:18     ` Jean-Philippe Brucker
2021-06-18  9:18       ` Jean-Philippe Brucker
2021-06-18  9:18       ` Jean-Philippe Brucker
2021-06-18  9:18       ` Jean-Philippe Brucker
2021-06-10  7:51 ` [PATCH v4 5/6] iommu/dma: Simplify calls " Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16 15:50   ` Eric Auger
2021-06-16 15:50     ` Eric Auger
2021-06-16 15:50     ` Eric Auger
2021-06-16 15:50     ` Eric Auger
2021-06-16 17:02   ` Robin Murphy [this message]
2021-06-16 17:02     ` Robin Murphy
2021-06-16 17:02     ` Robin Murphy
2021-06-16 17:02     ` Robin Murphy
2021-06-18 10:50     ` Jean-Philippe Brucker
2021-06-18 10:50       ` Jean-Philippe Brucker
2021-06-18 10:50       ` Jean-Philippe Brucker
2021-06-18 10:50       ` Jean-Philippe Brucker
2021-06-18 11:19       ` Robin Murphy
2021-06-18 11:19         ` Robin Murphy
2021-06-18 11:19         ` Robin Murphy
2021-06-18 11:19         ` Robin Murphy
2021-06-10  7:51 ` [PATCH v4 6/6] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-10  7:51   ` Jean-Philippe Brucker
2021-06-16 15:52   ` Eric Auger
2021-06-16 15:52     ` Eric Auger
2021-06-16 15:52     ` Eric Auger
2021-06-16 15:52     ` Eric Auger
2021-06-16  6:34 ` [PATCH v4 0/6] Add support for ACPI VIOT Jean-Philippe Brucker
2021-06-16  6:34   ` Jean-Philippe Brucker
2021-06-16  6:34   ` Jean-Philippe Brucker
2021-06-16  6:34   ` Jean-Philippe Brucker
2021-06-16 12:40 ` Eric Auger
2021-06-16 12:40   ` Eric Auger
2021-06-16 12:40   ` Eric Auger
2021-06-16 12:40   ` Eric Auger

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=6ce5fecb-fc81-5bf1-3577-6a09437b243e@arm.com \
    --to=robin.murphy@arm.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mst@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=sebastien.boeuf@intel.com \
    --cc=sudeep.holla@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will@kernel.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.