diff mbox series

[1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

Message ID 20190418172611.21561-2-julien.grall@arm.com
State New
Headers show
Series iommu/dma-iommu: Split iommu_dma_map_msi_msg in two parts | expand

Commit Message

Julien Grall April 18, 2019, 5:26 p.m. UTC 
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops domain.

At the moment, the allocation of the mapping may be done when composing
the message. However, the composing may be done in non-preemtible
context while the allocation requires to be called from preemptible
context.

A follow-up patch will split the current logic in two functions
requiring to keep an IOMMU cookie per MSI.

This patch introduces a new field in msi_desc to store an IOMMU cookie
when CONFIG_IOMMU_DMA is selected.

Signed-off-by: Julien Grall <julien.grall@arm.com>

---
 include/linux/msi.h | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.11.0

Comments

Thomas Gleixner April 18, 2019, 7:28 p.m. UTC | #1 
On Thu, 18 Apr 2019, Julien Grall wrote:

> When an MSI doorbell is located downstream of an IOMMU, it is required

> to swizzle the physical address with an appropriately-mapped IOVA for any

> device attached to one of our DMA ops domain.

> 

> At the moment, the allocation of the mapping may be done when composing

> the message. However, the composing may be done in non-preemtible

> context while the allocation requires to be called from preemptible

> context.

> 

> A follow-up patch will split the current logic in two functions

> requiring to keep an IOMMU cookie per MSI.

> 

> This patch introduces a new field in msi_desc to store an IOMMU cookie

> when CONFIG_IOMMU_DMA is selected.


# git grep 'This patch' Documentation/process/

Applied to the whole series.

Thanks

	tglx
Marc Zyngier April 23, 2019, 10:23 a.m. UTC | #2 
Hi Julien,

On 18/04/2019 18:26, Julien Grall wrote:
> When an MSI doorbell is located downstream of an IOMMU, it is required

> to swizzle the physical address with an appropriately-mapped IOVA for any

> device attached to one of our DMA ops domain.

> 

> At the moment, the allocation of the mapping may be done when composing

> the message. However, the composing may be done in non-preemtible

> context while the allocation requires to be called from preemptible

> context.

> 

> A follow-up patch will split the current logic in two functions

> requiring to keep an IOMMU cookie per MSI.

> 

> This patch introduces a new field in msi_desc to store an IOMMU cookie

> when CONFIG_IOMMU_DMA is selected.

> 

> Signed-off-by: Julien Grall <julien.grall@arm.com>

> ---

>  include/linux/msi.h | 3 +++

>  1 file changed, 3 insertions(+)

> 

> diff --git a/include/linux/msi.h b/include/linux/msi.h

> index 7e9b81c3b50d..d7907feef1bb 100644

> --- a/include/linux/msi.h

> +++ b/include/linux/msi.h

> @@ -77,6 +77,9 @@ struct msi_desc {

>  	struct device			*dev;

>  	struct msi_msg			msg;

>  	struct irq_affinity_desc	*affinity;

> +#ifdef CONFIG_IOMMU_DMA

> +	const void			*iommu_cookie;

> +#endif

>  

>  	union {

>  		/* PCI MSI/X specific data */

> 


Given that this is the only member in this structure that is dependent
on a config option, you could also add a couple of accessors that would
do nothing when IOMMU_DMA is not selected (and use that in the DMA code).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
Julien Grall April 23, 2019, 10:51 a.m. UTC | #3 
On 4/23/19 11:23 AM, Marc Zyngier wrote:
> Hi Julien,


Hi Marc,

> On 18/04/2019 18:26, Julien Grall wrote:

>> When an MSI doorbell is located downstream of an IOMMU, it is required

>> to swizzle the physical address with an appropriately-mapped IOVA for any

>> device attached to one of our DMA ops domain.

>>

>> At the moment, the allocation of the mapping may be done when composing

>> the message. However, the composing may be done in non-preemtible

>> context while the allocation requires to be called from preemptible

>> context.

>>

>> A follow-up patch will split the current logic in two functions

>> requiring to keep an IOMMU cookie per MSI.

>>

>> This patch introduces a new field in msi_desc to store an IOMMU cookie

>> when CONFIG_IOMMU_DMA is selected.

>>

>> Signed-off-by: Julien Grall <julien.grall@arm.com>

>> ---

>>   include/linux/msi.h | 3 +++

>>   1 file changed, 3 insertions(+)

>>

>> diff --git a/include/linux/msi.h b/include/linux/msi.h

>> index 7e9b81c3b50d..d7907feef1bb 100644

>> --- a/include/linux/msi.h

>> +++ b/include/linux/msi.h

>> @@ -77,6 +77,9 @@ struct msi_desc {

>>   	struct device			*dev;

>>   	struct msi_msg			msg;

>>   	struct irq_affinity_desc	*affinity;

>> +#ifdef CONFIG_IOMMU_DMA

>> +	const void			*iommu_cookie;

>> +#endif

>>   

>>   	union {

>>   		/* PCI MSI/X specific data */

>>

> 

> Given that this is the only member in this structure that is dependent

> on a config option, you could also add a couple of accessors that would

> do nothing when IOMMU_DMA is not selected (and use that in the DMA code).


I haven't seen any use of the helpers so far because the DMA code is 
also protected by IOMMU_DMA.

I can add the helpers in the next version if you see any use outside of 
the DMA code.

Cheers,

-- 
Julien Grall
Robin Murphy April 23, 2019, 1:19 p.m. UTC | #4 
On 23/04/2019 12:46, Marc Zyngier wrote:
> On 23/04/2019 11:51, Julien Grall wrote:

>> On 4/23/19 11:23 AM, Marc Zyngier wrote:

>>> Hi Julien,

>>

>> Hi Marc,

>>

>>> On 18/04/2019 18:26, Julien Grall wrote:

>>>> When an MSI doorbell is located downstream of an IOMMU, it is required

>>>> to swizzle the physical address with an appropriately-mapped IOVA for any

>>>> device attached to one of our DMA ops domain.

>>>>

>>>> At the moment, the allocation of the mapping may be done when composing

>>>> the message. However, the composing may be done in non-preemtible

>>>> context while the allocation requires to be called from preemptible

>>>> context.

>>>>

>>>> A follow-up patch will split the current logic in two functions

>>>> requiring to keep an IOMMU cookie per MSI.

>>>>

>>>> This patch introduces a new field in msi_desc to store an IOMMU cookie

>>>> when CONFIG_IOMMU_DMA is selected.

>>>>

>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>

>>>> ---

>>>>    include/linux/msi.h | 3 +++

>>>>    1 file changed, 3 insertions(+)

>>>>

>>>> diff --git a/include/linux/msi.h b/include/linux/msi.h

>>>> index 7e9b81c3b50d..d7907feef1bb 100644

>>>> --- a/include/linux/msi.h

>>>> +++ b/include/linux/msi.h

>>>> @@ -77,6 +77,9 @@ struct msi_desc {

>>>>    	struct device			*dev;

>>>>    	struct msi_msg			msg;

>>>>    	struct irq_affinity_desc	*affinity;

>>>> +#ifdef CONFIG_IOMMU_DMA

>>>> +	const void			*iommu_cookie;

>>>> +#endif

>>>>    

>>>>    	union {

>>>>    		/* PCI MSI/X specific data */

>>>>

>>>

>>> Given that this is the only member in this structure that is dependent

>>> on a config option, you could also add a couple of accessors that would

>>> do nothing when IOMMU_DMA is not selected (and use that in the DMA code).

>>

>> I haven't seen any use of the helpers so far because the DMA code is

>> also protected by IOMMU_DMA.

>>

>> I can add the helpers in the next version if you see any use outside of

>> the DMA code.

> 

> There may not be any user user yet, but I'd surely like to see the

> accessors. This isn't very different from the stub functions you add in

> patch #2.


If you foresee this being useful in general, do you reckon it would be 
worth decoupling it under its own irqchip-layer Kconfig which can then 
be selected by IOMMU_DMA?

Robin.
Marc Zyngier April 23, 2019, 1:42 p.m. UTC | #5 
On 23/04/2019 14:19, Robin Murphy wrote:
> On 23/04/2019 12:46, Marc Zyngier wrote:

>> On 23/04/2019 11:51, Julien Grall wrote:

>>> On 4/23/19 11:23 AM, Marc Zyngier wrote:

>>>> Hi Julien,

>>>

>>> Hi Marc,

>>>

>>>> On 18/04/2019 18:26, Julien Grall wrote:

>>>>> When an MSI doorbell is located downstream of an IOMMU, it is required

>>>>> to swizzle the physical address with an appropriately-mapped IOVA for any

>>>>> device attached to one of our DMA ops domain.

>>>>>

>>>>> At the moment, the allocation of the mapping may be done when composing

>>>>> the message. However, the composing may be done in non-preemtible

>>>>> context while the allocation requires to be called from preemptible

>>>>> context.

>>>>>

>>>>> A follow-up patch will split the current logic in two functions

>>>>> requiring to keep an IOMMU cookie per MSI.

>>>>>

>>>>> This patch introduces a new field in msi_desc to store an IOMMU cookie

>>>>> when CONFIG_IOMMU_DMA is selected.

>>>>>

>>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>

>>>>> ---

>>>>>    include/linux/msi.h | 3 +++

>>>>>    1 file changed, 3 insertions(+)

>>>>>

>>>>> diff --git a/include/linux/msi.h b/include/linux/msi.h

>>>>> index 7e9b81c3b50d..d7907feef1bb 100644

>>>>> --- a/include/linux/msi.h

>>>>> +++ b/include/linux/msi.h

>>>>> @@ -77,6 +77,9 @@ struct msi_desc {

>>>>>    	struct device			*dev;

>>>>>    	struct msi_msg			msg;

>>>>>    	struct irq_affinity_desc	*affinity;

>>>>> +#ifdef CONFIG_IOMMU_DMA

>>>>> +	const void			*iommu_cookie;

>>>>> +#endif

>>>>>    

>>>>>    	union {

>>>>>    		/* PCI MSI/X specific data */

>>>>>

>>>>

>>>> Given that this is the only member in this structure that is dependent

>>>> on a config option, you could also add a couple of accessors that would

>>>> do nothing when IOMMU_DMA is not selected (and use that in the DMA code).

>>>

>>> I haven't seen any use of the helpers so far because the DMA code is

>>> also protected by IOMMU_DMA.

>>>

>>> I can add the helpers in the next version if you see any use outside of

>>> the DMA code.

>>

>> There may not be any user user yet, but I'd surely like to see the

>> accessors. This isn't very different from the stub functions you add in

>> patch #2.

> 

> If you foresee this being useful in general, do you reckon it would be 

> worth decoupling it under its own irqchip-layer Kconfig which can then 

> be selected by IOMMU_DMA?


I think that'd be a useful thing to do, as most architectures do not
require this dynamic mapping of MSIs.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
diff mbox series

Patch

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 7e9b81c3b50d..d7907feef1bb 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -77,6 +77,9 @@  struct msi_desc {
 	struct device			*dev;
 	struct msi_msg			msg;
 	struct irq_affinity_desc	*affinity;
+#ifdef CONFIG_IOMMU_DMA
+	const void			*iommu_cookie;
+#endif
 
 	union {
 		/* PCI MSI/X specific data */