Re: [Xen-devel] swiotlb-xen question

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

Hi, Stefano.

Thank You for advice.

I'll try this few days later.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Wed, Mar 26, 2014 at 8:49 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Wed, 26 Mar 2014, Oleksandr Dmytryshyn wrote:
>> On Wed, Mar 26, 2014 at 4:46 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@xxxxxxxxxx> wrote:
>> > On Wed, Mar 26, 2014 at 12:35:12PM +0200, Oleksandr Dmytryshyn wrote:
>> >> Hi to all.
>> >>
>> >> Currently I'm using hypervisor on ARM Cortex A15 processor (DRA7xx
>> >> Jacinto 6 processor). I'm using mainline xen 4.4 with some patches on
>> >> top plus dom0 and domU linux kernel 3.8.
>> >>
>> >> I've written a hack to make a camera working on my board in dom0
>> >> (drivers for camera and display system are in dom0). An user-space
>> >> application in dom0 is used to test camera (it reads camera captured
>> >> data and sends it to the framebuffer). In the kernel code I've implemented
>> >> .mmap callback function in the swiotlb-xen.c file (like 
>> >> xen_swiotlb_mmap())
>> >> and copied to this new callback all content from the original function
>> >> 'arm_dma_mmap()' from the kernel. This function creates userspace
>> >> mapping for the DMA-coherent memory. With this hack camera is working
>> >> (I can see captured video on display).
>> >
>> > Why can't you use the v4l API? Won't that work?
>> >
>> Currently we are using v4l api. swiotlb-xen doesnt have mmap callback
>> implemented,
>> so kernel use standard function dma_common_mmap() to map memory. But this
>> function doesn't work correctly. We've also tried to use arm_dma_mmap() 
>> function
>> instead of the dma_common_mmap() (HACK in the file
>> include/asm-generic/dma-mapping-common.h only for dom0) and all is working
>> in this case.
>
> This is not a Xen specific issue.
> In fact unless some of the dma pages involved could be foreign guest
> pages (for example because you have a PV framebuffer frontend in a guest
> sharing pages with a framebuffer backend in Dom0, and these pages are
> used directly in your camera driver), swiotlb-xen shouldn't even be
> involved.
>
> The problem is that on ARM, when you call virt_to_phys on a virtual
> address returned by dma_alloc_from_coherent, it doesn't return the right
> physical address.
> For example:
>
> virt_address = dma_alloc_from_coherent(dev, size, dma_addr, &ret);
> virt_to_phys(virt_address) != dma_addr
>
> The issue is not that bus addresses are different from physical
> addresses. The problem is that the virtual address is an ioremap address
> therefore virt_to_phys and virt_to_page don't work as expected.
>
> To fix your problem you can simply:
>
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 0ce39a3..052a5ed 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -248,7 +248,7 @@ int dma_common_mmap(struct device *dev, struct 
> vm_area_struct *vma,
>  #ifdef CONFIG_MMU
>         unsigned long user_count = (vma->vm_end - vma->vm_start) >> 
> PAGE_SHIFT;
>         unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> -       unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
> +       unsigned long pfn = dma_addr >> PAGE_SHIFT;
>         unsigned long off = vma->vm_pgoff;
>
>         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> however that would cause problems on architectures for which bus
> addresses are different from physical addresses.
> Alternatively you could:
>
> +       unsigned long pfn = bus_to_phys(dma_addr) >> PAGE_SHIFT;
>
> however bus_to_phys is not defined on all architectures.
> I am not sure what is the best way to fix this in common code such us
> drivers/base/dma-mapping.c.

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