Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681321 > unrolled thread

[RFC PATCH 0/5] Fixes for loadable modules implementing DMA/IOMMU APIs

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/5] Fixes for loadable modules implementing DMA/IOMMU APIs Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    [RFC PATCH 5/5] iommu/dma: Add iommu_dma_cleanup() Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    [RFC PATCH 2/5] base: dma-mapping: Provide a function to look up remapped pages Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    [RFC PATCH 3/5] iommu: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
      Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Christoph Hellwig <hch@lst.de> - 2017-07-05 17:20 +0200
        Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-05 17:30 +0200
          Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Christoph Hellwig <hch@lst.de> - 2017-07-05 19:30 +0200
            Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 03:50 +0200
              Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 10:30 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 10:40 +0200
                  Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 10:50 +0200
                    Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 14:30 +0200
                      Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 15:40 +0200
                        Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 15:50 +0200
                          Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:10 +0200
                            Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:30 +0200
                              Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:40 +0200
                          Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:10 +0200
                        Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:00 +0200
    [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
      Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in  modules Robin Murphy <robin.murphy@arm.com> - 2017-07-05 18:30 +0200
        Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 04:30 +0200
          Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in  modules Robin Murphy <robin.murphy@arm.com> - 2017-07-06 13:20 +0200
            Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use         in modules Christoph Hellwig <hch@lst.de> - 2017-07-06 16:20 +0200
              Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:20 +0200
                Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:30 +0200
                  Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:40 +0200
                    Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1681336 — [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

There is nothing wrong in having a loadable module implementing DMA API,
for example to be used for sub-devices registered by the module. However,
most of the functions from dma-iommu do not have their symbols exported,
making it impossible to use them from loadable modules.

Export all the non-static functions in the file, so that loadable modules
can benefit from them. Use EXPORT_SYMBOL() for consistency with other
exports in the file.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
---
 drivers/iommu/dma-iommu.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe7f6cb..7cdeaf930106 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -80,6 +80,7 @@ int iommu_dma_init(void)
 {
 	return iova_cache_get();
 }
+EXPORT_SYMBOL(iommu_dma_init);
 
 /**
  * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
@@ -357,6 +358,7 @@ int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
 		return 0;
 	}
 }
+EXPORT_SYMBOL(dma_info_to_prot);
 
 static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain *domain,
 		size_t size, dma_addr_t dma_limit, struct device *dev)
@@ -504,6 +506,7 @@ void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
 	__iommu_dma_free_pages(pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
 	*handle = IOMMU_MAPPING_ERROR;
 }
+EXPORT_SYMBOL(iommu_dma_free);
 
 /**
  * iommu_dma_alloc - Allocate and map a buffer contiguous in IOVA space
@@ -588,6 +591,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
 	__iommu_dma_free_pages(pages, count);
 	return NULL;
 }
+EXPORT_SYMBOL(iommu_dma_alloc);
 
 /**
  * iommu_dma_mmap - Map a buffer into provided user VMA
@@ -613,6 +617,7 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
 	}
 	return ret;
 }
+EXPORT_SYMBOL(iommu_dma_mmap);
 
 static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
 		size_t size, int prot)
@@ -643,12 +648,14 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
 {
 	return __iommu_dma_map(dev, page_to_phys(page) + offset, size, prot);
 }
+EXPORT_SYMBOL(iommu_dma_map_page);
 
 void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
 		enum dma_data_direction dir, unsigned long attrs)
 {
 	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
 }
+EXPORT_SYMBOL(iommu_dma_unmap_page);
 
 /*
  * Prepare a successfully-mapped scatterlist to give back to the caller.
@@ -802,6 +809,7 @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
 	__invalidate_sg(sg, nents);
 	return 0;
 }
+EXPORT_SYMBOL(iommu_dma_map_sg);
 
 void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 		enum dma_data_direction dir, unsigned long attrs)
@@ -822,6 +830,7 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 	end = sg_dma_address(sg) + sg_dma_len(sg);
 	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), start, end - start);
 }
+EXPORT_SYMBOL(iommu_dma_unmap_sg);
 
 dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
@@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
 	return __iommu_dma_map(dev, phys, size,
 			dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
 }
+EXPORT_SYMBOL(iommu_dma_map_resource);
 
 void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
 	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
 }
+EXPORT_SYMBOL(iommu_dma_unmap_resource);
 
 int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 {
 	return dma_addr == IOMMU_MAPPING_ERROR;
 }
+EXPORT_SYMBOL(iommu_dma_mapping_error);
 
 static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
 		phys_addr_t msi_addr, struct iommu_domain *domain)
@@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
 		msg->address_lo += lower_32_bits(msi_page->iova);
 	}
 }
+EXPORT_SYMBOL(iommu_dma_map_msi_msg);
-- 
2.13.2.725.g09c95d1e9-goog

[toc] | [prev] | [next] | [standalone]

#1681641 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On 05/07/17 08:12, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for sub-devices registered by the module. However,
> most of the functions from dma-iommu do not have their symbols exported,
> making it impossible to use them from loadable modules.
> 
> Export all the non-static functions in the file, so that loadable modules
> can benefit from them. Use EXPORT_SYMBOL() for consistency with other
> exports in the file.

To echo what Christoph said, everything not already exported here
shouldn't in any way be considered a driver-facing API in the general
sense, it's horrible glue code to sit behind an arch-specific DMA
mapping implementation (and frankly I'd consider even the current
exports more of an unfortunate abstraction leakage).

> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> ---

[...]

> @@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
>  	return __iommu_dma_map(dev, phys, size,
>  			dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>  }
> +EXPORT_SYMBOL(iommu_dma_map_resource);
>  
>  void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir, unsigned long attrs)
>  {
>  	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
>  }
> +EXPORT_SYMBOL(iommu_dma_unmap_resource);

Do you need these two? Unless your custom DMA ops really have to support
slave DMA or other peer-to-peer traffic through their IOMMU, I'd be more
inclined to implement dma_map_resource as "return 0;" and ignore
dma_unmap_resource.

> @@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>  		msg->address_lo += lower_32_bits(msi_page->iova);
>  	}
>  }
> +EXPORT_SYMBOL(iommu_dma_map_msi_msg);

Given the nature of the kind of irqchip drivers this exists for, the
chances of one ever being modular seem vanishingly small.

Robin.

[toc] | [prev] | [next] | [standalone]

#1682017 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 6, 2017 at 1:22 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 05/07/17 08:12, Tomasz Figa wrote:
>> There is nothing wrong in having a loadable module implementing DMA API,
>> for example to be used for sub-devices registered by the module. However,
>> most of the functions from dma-iommu do not have their symbols exported,
>> making it impossible to use them from loadable modules.
>>
>> Export all the non-static functions in the file, so that loadable modules
>> can benefit from them. Use EXPORT_SYMBOL() for consistency with other
>> exports in the file.
>
> To echo what Christoph said, everything not already exported here
> shouldn't in any way be considered a driver-facing API in the general
> sense, it's horrible glue code to sit behind an arch-specific DMA
> mapping implementation (and frankly I'd consider even the current
> exports more of an unfortunate abstraction leakage).

Well, if I remember correctly, we agreed that the IPU3 driver would
benefit from using all the iommu_dma_*() helpers in its DMA ops,
similarly to ARM64. This is IMHO much better than re-implementing them
again internally just for this driver. However almost none of
necessary helpers are currently exported...

>
>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>> ---
>
> [...]
>
>> @@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
>>       return __iommu_dma_map(dev, phys, size,
>>                       dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>>  }
>> +EXPORT_SYMBOL(iommu_dma_map_resource);
>>
>>  void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>>               size_t size, enum dma_data_direction dir, unsigned long attrs)
>>  {
>>       __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
>>  }
>> +EXPORT_SYMBOL(iommu_dma_unmap_resource);
>
> Do you need these two? Unless your custom DMA ops really have to support
> slave DMA or other peer-to-peer traffic through their IOMMU, I'd be more
> inclined to implement dma_map_resource as "return 0;" and ignore
> dma_unmap_resource.

I don't need them. Getting an idea what is desirable to export and
what not is actually one of the goals of this RFC.

>
>> @@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>>               msg->address_lo += lower_32_bits(msi_page->iova);
>>       }
>>  }
>> +EXPORT_SYMBOL(iommu_dma_map_msi_msg);
>
> Given the nature of the kind of irqchip drivers this exists for, the
> chances of one ever being modular seem vanishingly small.

Agreed. The IPU3 driver does not need it either.

Let me list the (not yet exported) helpers it requires:

dma-iommu.c
 - iommu_dma_init,
 - dma_info_to_prot,
 - iommu_dma_free,
 - iommu_dma_alloc,
 - iommu_dma_mmap,
 - iommu_dma_map_page,
 - iommu_dma_unmap_page,
 - iommu_dma_map_sg,
 - iommu_dma_unmap_sg,
 - iommu_dma_mapping_error,
(added by my patch) iommu_dma_cleanup,

iommu.c
 - iommu_group_get_for_dev,

base/dma-mapping.c
 - dma_common_pages_remap,
 - dma_common_free_remap,
(added by my patch) dma_common_get_mapped_pages (OR find_vm_area),

Best regards,
Tomasz

[toc] | [prev] | [next] | [standalone]

#1682362 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On 06/07/17 03:25, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 1:22 AM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 05/07/17 08:12, Tomasz Figa wrote:
>>> There is nothing wrong in having a loadable module implementing DMA API,
>>> for example to be used for sub-devices registered by the module. However,
>>> most of the functions from dma-iommu do not have their symbols exported,
>>> making it impossible to use them from loadable modules.
>>>
>>> Export all the non-static functions in the file, so that loadable modules
>>> can benefit from them. Use EXPORT_SYMBOL() for consistency with other
>>> exports in the file.
>>
>> To echo what Christoph said, everything not already exported here
>> shouldn't in any way be considered a driver-facing API in the general
>> sense, it's horrible glue code to sit behind an arch-specific DMA
>> mapping implementation (and frankly I'd consider even the current
>> exports more of an unfortunate abstraction leakage).
> 
> Well, if I remember correctly, we agreed that the IPU3 driver would
> benefit from using all the iommu_dma_*() helpers in its DMA ops,
> similarly to ARM64. This is IMHO much better than re-implementing them
> again internally just for this driver. However almost none of
> necessary helpers are currently exported...

Oh, for sure - I don't personally have much objection to arch code being
modular (even as part of a driver subsystem), I just don't want anyone
to get the impression that this layer is something that any old driver
can dip into as it fancies.

>>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>>> ---
>>
>> [...]
>>
>>> @@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
>>>       return __iommu_dma_map(dev, phys, size,
>>>                       dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>>>  }
>>> +EXPORT_SYMBOL(iommu_dma_map_resource);
>>>
>>>  void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>>>               size_t size, enum dma_data_direction dir, unsigned long attrs)
>>>  {
>>>       __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
>>>  }
>>> +EXPORT_SYMBOL(iommu_dma_unmap_resource);
>>
>> Do you need these two? Unless your custom DMA ops really have to support
>> slave DMA or other peer-to-peer traffic through their IOMMU, I'd be more
>> inclined to implement dma_map_resource as "return 0;" and ignore
>> dma_unmap_resource.
> 
> I don't need them. Getting an idea what is desirable to export and
> what not is actually one of the goals of this RFC.
> 
>>
>>> @@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>>>               msg->address_lo += lower_32_bits(msi_page->iova);
>>>       }
>>>  }
>>> +EXPORT_SYMBOL(iommu_dma_map_msi_msg);
>>
>> Given the nature of the kind of irqchip drivers this exists for, the
>> chances of one ever being modular seem vanishingly small.
> 
> Agreed. The IPU3 driver does not need it either.
> 
> Let me list the (not yet exported) helpers it requires:
> 
> dma-iommu.c
>  - iommu_dma_init,
>  - dma_info_to_prot,
>  - iommu_dma_free,
>  - iommu_dma_alloc,
>  - iommu_dma_mmap,
>  - iommu_dma_map_page,
>  - iommu_dma_unmap_page,
>  - iommu_dma_map_sg,
>  - iommu_dma_unmap_sg,
>  - iommu_dma_mapping_error,
> (added by my patch) iommu_dma_cleanup,
> 
> iommu.c
>  - iommu_group_get_for_dev,
> 
> base/dma-mapping.c
>  - dma_common_pages_remap,
>  - dma_common_free_remap,
> (added by my patch) dma_common_get_mapped_pages (OR find_vm_area),

I suppose another option is to just make the IOMMU and DMA ops a
self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
code, the latter more or less just needs to create the appropriate IOMMU
device for the driver to find.

Robin.

> 
> Best regards,
> Tomasz
> 

[toc] | [prev] | [next] | [standalone]

#1682461 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
> I suppose another option is to just make the IOMMU and DMA ops a
> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
> code, the latter more or less just needs to create the appropriate IOMMU
> device for the driver to find.

I still haven't seen the driver code, but this seems to be best
solution so far.  Given that it's not a plug in device but part of
an SOC that seems perfectly acceptable to me.

[toc] | [prev] | [next] | [standalone]

#1682463 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>> I suppose another option is to just make the IOMMU and DMA ops a
>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
>> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
>> code, the latter more or less just needs to create the appropriate IOMMU
>> device for the driver to find.
>
> I still haven't seen the driver code, but this seems to be best
> solution so far.  Given that it's not a plug in device but part of
> an SOC that seems perfectly acceptable to me.

I guess that's something that could work. With its caveats of not
being able to avoid including the very platform specific code in a
generic kernel image or do any quick testing of code changes without a
restart, but I guess that's something one could quickly hack in their
own downstream (i.e. export the symbols and turn the Kconfig entry
into tristate).

On the other hand, I'm yet to see any real reasons why not to export
those symbols. Personally I don't see anything that one wouldn't be
able to do in their downstream without the symbols exported in
mainline (one can add the exports any time or if the kernel source
can't be modified can just load a wrapper module that exports its own
symbols...)

Best regards,
Tomasz

[toc] | [prev] | [next] | [standalone]

#1682467 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa <tfiga@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig <hch@lst.de> wrote:
>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>>> I suppose another option is to just make the IOMMU and DMA ops a
>>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
>>> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
>>> code, the latter more or less just needs to create the appropriate IOMMU
>>> device for the driver to find.
>>
>> I still haven't seen the driver code, but this seems to be best
>> solution so far.  Given that it's not a plug in device but part of
>> an SOC that seems perfectly acceptable to me.
>
> I guess that's something that could work. With its caveats of not
> being able to avoid including the very platform specific code in a
> generic kernel image or do any quick testing of code changes without a
> restart, but I guess that's something one could quickly hack in their
> own downstream (i.e. export the symbols and turn the Kconfig entry
> into tristate).
>
> On the other hand, I'm yet to see any real reasons why not to export
> those symbols. Personally I don't see anything that one wouldn't be
> able to do in their downstream without the symbols exported in
> mainline (one can add the exports any time or if the kernel source
> can't be modified can just load a wrapper module that exports its own
> symbols...)

Sorry, I just realized that last sentence might sound nonsense. By
wrapper I meant reimplementing the missing functions using some
already exported functions I mentioned in my post to another patch
from this series, such as __get_vm_area() and map_vm_area().

[toc] | [prev] | [next] | [standalone]

#1682480 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa <tfiga@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig <hch@lst.de> wrote:
>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>>>> I suppose another option is to just make the IOMMU and DMA ops a
>>>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
>>>> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
>>>> code, the latter more or less just needs to create the appropriate IOMMU
>>>> device for the driver to find.
>>>
>>> I still haven't seen the driver code, but this seems to be best
>>> solution so far.  Given that it's not a plug in device but part of
>>> an SOC that seems perfectly acceptable to me.
>>
>> I guess that's something that could work. With its caveats of not
>> being able to avoid including the very platform specific code in a
>> generic kernel image or do any quick testing of code changes without a
>> restart, but I guess that's something one could quickly hack in their
>> own downstream (i.e. export the symbols and turn the Kconfig entry
>> into tristate).
>>
>> On the other hand, I'm yet to see any real reasons why not to export
>> those symbols. Personally I don't see anything that one wouldn't be
>> able to do in their downstream without the symbols exported in
>> mainline (one can add the exports any time or if the kernel source
>> can't be modified can just load a wrapper module that exports its own
>> symbols...)
>
> Sorry, I just realized that last sentence might sound nonsense. By
> wrapper I meant reimplementing the missing functions using some
> already exported functions I mentioned in my post to another patch
> from this series, such as __get_vm_area() and map_vm_area().

We should look at the two aspects separately: one is how to drive
the IOMMU as part of a loadable driver, the other is how to handle
DMA to uncached memory on x86. You are in an unfortunate
position of needing both, but aside from that they seem unrelated.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1682489 — Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

On Thu, Jul 6, 2017 at 11:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa <tfiga@chromium.org> wrote:
>>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig <hch@lst.de> wrote:
>>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>>>>> I suppose another option is to just make the IOMMU and DMA ops a
>>>>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
>>>>> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
>>>>> code, the latter more or less just needs to create the appropriate IOMMU
>>>>> device for the driver to find.
>>>>
>>>> I still haven't seen the driver code, but this seems to be best
>>>> solution so far.  Given that it's not a plug in device but part of
>>>> an SOC that seems perfectly acceptable to me.
>>>
>>> I guess that's something that could work. With its caveats of not
>>> being able to avoid including the very platform specific code in a
>>> generic kernel image or do any quick testing of code changes without a
>>> restart, but I guess that's something one could quickly hack in their
>>> own downstream (i.e. export the symbols and turn the Kconfig entry
>>> into tristate).
>>>
>>> On the other hand, I'm yet to see any real reasons why not to export
>>> those symbols. Personally I don't see anything that one wouldn't be
>>> able to do in their downstream without the symbols exported in
>>> mainline (one can add the exports any time or if the kernel source
>>> can't be modified can just load a wrapper module that exports its own
>>> symbols...)
>>
>> Sorry, I just realized that last sentence might sound nonsense. By
>> wrapper I meant reimplementing the missing functions using some
>> already exported functions I mentioned in my post to another patch
>> from this series, such as __get_vm_area() and map_vm_area().
>
> We should look at the two aspects separately: one is how to drive
> the IOMMU as part of a loadable driver, the other is how to handle
> DMA to uncached memory on x86. You are in an unfortunate
> position of needing both, but aside from that they seem unrelated.

So generally I'm not in such a desperate need to have this code as a
loadable module. I can just hack around it in my own working tree if I
need it. However I'm trying to understand, why this is such a bad
idea, if I already have it working.

Uncached DMA memory on x86 is actually more complicated. We could
still work around this by not relying on the memory being uncached
(with caveats obviously). But here too I'd like to understand why
having my own DMA ops is bad.

Best regards,
Tomasz

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web