[RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Some drivers need additional dma ops to be provided by xen swiotlb. Because
common operations implementation came from x86 world and does not suite ARM
needs.

dma_mmap patch is a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel&m=139695901430667&w=4

Andrii Anisov (1):
  swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Stefano Stabellini (1):
  swiotlb-xen: implement xen_swiotlb_dma_mmap callback

 arch/arm/xen/mm.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[RFC 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

[Andrii Anisov]

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 arch/arm/xen/mm.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index c5f9a9e..050cf34 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -163,6 +163,19 @@ bool xen_arch_need_swiotlb(struct device *dev,
 		!is_device_dma_coherent(dev));
 }
 
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ */
+static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+			 void *cpu_addr, dma_addr_t dma_addr, size_t size,
+			 struct dma_attrs *attrs)
+{
+	if (__generic_dma_ops(dev)->mmap)
+		return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+
+	return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
@@ -199,6 +212,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
 	.set_dma_mask = xen_swiotlb_set_dma_mask,
+	.mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[RFC 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 arch/arm/xen/mm.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 050cf34..4061dd0 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -176,6 +176,16 @@ static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
 	return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 
+static int xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+				 void *cpu_addr, dma_addr_t handle, size_t size,
+				 struct dma_attrs *attrs)
+{
+	if (__generic_dma_ops(dev)->get_sgtable)
+		return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr, handle,
+								 size, attrs);
+	return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 				 unsigned int address_bits,
 				 dma_addr_t *dma_handle)
@@ -213,6 +223,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.dma_supported = xen_swiotlb_dma_supported,
 	.set_dma_mask = xen_swiotlb_set_dma_mask,
 	.mmap = xen_swiotlb_dma_mmap,
+	.get_sgtable = xen_swiotlb_get_sgtable,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Konrad Rzeszutek Wilk]

On Tue, Jan 10, 2017 at 06:44:25PM +0200, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> Some drivers need additional dma ops to be provided by xen swiotlb. Because
> common operations implementation came from x86 world and does not suite ARM
> needs.
> 
> dma_mmap patch is a port of an antique and lost patch discussed here:
> http://marc.info/?l=xen-devel&m=139695901430667&w=4

It would be good to have that as part of this patchset, otherwise
this is kind of non-compiling type patch.

But more importantly, I think you need to also to take into account
Stefano's comments:

http://marc.info/?l=xen-devel&m=139991966525561&w=4

> 
> Andrii Anisov (1):
>   swiotlb-xen: implement xen_swiotlb_get_sgtable callback
> 
> Stefano Stabellini (1):
>   swiotlb-xen: implement xen_swiotlb_dma_mmap callback
> 
>  arch/arm/xen/mm.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Andrii Anisov]

Dear Konrad,

Please see my comments below:
> It would be good to have that as part of this patchset, otherwise
> this is kind of non-compiling type patch.
I'm not really sure what do you mean.
The patch I refer was done for LK 3.4 if I remember, it is not 
applicable to 4.6 I'm currently working with.
Moreover xen-swiotlb infrastructure changed significantly so the patch 
is completely reworked. The only
common code is that mmap is defined in ARM specific xen_swiotlb_dma_ops.
I just refer to it and left author and signed-of-s as a respect to the 
work done few years ago.

> But more importantly, I think you need to also to take into account
> Stefano's comments:
I've encapsulated all the code changes in an arch/arm/xen/mm.c so I 
don't think your doubts and Stephano's comment
about x86 build impact is relevant here.

-- 

*Andrii Anisov*

*Lead Systems Engineer*

*Office: *+380 44 390 5457 <tel:+380%2044%20390%205457> *x* 66766 
<tel:66766>*Cell: *+380 50 5738852 <tel:+380%2050%205738852>*Email: 
*andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>

*Kyiv**,* *Ukraine *(GMT+3)*epam.com <http://www.epam.com>*

CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or 
entity(ies) to which it is addressed and contains information that is 
legally privileged and confidential. If you are not the intended 
recipient, or the person responsible for delivering the message to the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. 
All unintended recipients are obliged to delete this message and destroy 
any printed copies.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [RFC 0/2] XEN SWIOTLB for ARM dma operations extension

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2017 at 06:09:03PM +0200, Andrii Anisov wrote:
> Dear Konrad,
> 
> Please see my comments below:
> > It would be good to have that as part of this patchset, otherwise
> > this is kind of non-compiling type patch.
> I'm not really sure what do you mean.

As in attaching an rework of the patch to this patchset.

> The patch I refer was done for LK 3.4 if I remember, it is not applicable to
> 4.6 I'm currently working with.
> Moreover xen-swiotlb infrastructure changed significantly so the patch is
> completely reworked. The only
> common code is that mmap is defined in ARM specific xen_swiotlb_dma_ops.
> I just refer to it and left author and signed-of-s as a respect to the work
> done few years ago.
> 
> > But more importantly, I think you need to also to take into account
> > Stefano's comments:
> I've encapsulated all the code changes in an arch/arm/xen/mm.c so I don't
> think your doubts and Stephano's comment
> about x86 build impact is relevant here.
> 
> -- 
> 
> *Andrii Anisov*
> 
> *Lead Systems Engineer*
> 
> *Office: *+380 44 390 5457 <tel:+380%2044%20390%205457> *x* 66766
> <tel:66766>*Cell: *+380 50 5738852 <tel:+380%2050%205738852>*Email:
> *andrii_anisov@epam.com <mailto:andrii_anisov@epam.com>
> 
> *Kyiv**,* *Ukraine *(GMT+3)*epam.com <http://www.epam.com>*
> 
> CONFIDENTIALITY CAUTION AND DISCLAIMER
> This message is intended only for the use of the individual(s) or
> entity(ies) to which it is addressed and contains information that is
> legally privileged and confidential. If you are not the intended recipient,
> or the person responsible for delivering the message to the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. All unintended
> recipients are obliged to delete this message and destroy any printed
> copies.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel