Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> > On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> >>
> >> Firstly sorry for the late reply on this.
> >>
> >> Regarding the problem with swiotlb-xen here are some more details:
> >>
> >> If we limit Dom0's memory such that only low-memory (up to 32-bit 
> >> addressable memory) is available to Dom0, then swiotlb-xen does not have 
> >> to use bounce buffers and the devices (e.g. USB, ethernet) would work.
> >>
> >> But when there is some high memory also available to Dom0, the followings 
> >> happen:
> >>  - If the the device address happens to be in the device's DMA window (see 
> >> xen_swiotlb_map_page()), then the device would work.
> >>  - Otherwise if it has to allocate and map a bounce buffer, then the 
> >> device would not work.
> > 
> > From what you wrote it looks like the xen_swiotlb_map_page path: 
> > 
> >     if (dma_capable(dev, dev_addr, size) &&
> >         !range_straddles_page_boundary(phys, size) &&
> >             !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
> >             !swiotlb_force) {
> >             /* we are not interested in the dma_addr returned by
> >              * xen_dma_map_page, only in the potential cache flushes 
> > executed
> >              * by the function. */
> >             xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
> >             return dev_addr;
> >     }
> > 
> > works, but the other does not. Does it match your understanding? Have
> > you done any digging to find the reason why the bounce buffer code path
> > is broken on your platform?
> 
> Yes, The above path works but the other one doesn't.
> I did some digging but failed to find out what's the problem. The returned 
> address from swiotlb_tbl_map_single() is within the memory range allocated 
> earlier for Xen software IO TLB and is dma capable, so it seem to be OK.
> 
> What's your suggestion for further digging?

Is the device DMA coherent?
I take that it fails even without running any guests, correct?


A few things come to mind:

- In xen_dma_map_page, does it take the local path or the foreign path
  (if(local)...) when it fails?

- Check that xen_swiotlb_init initializes the swiotlb memory region
  appriopriately and that it falls in a memory range supported by the
  device.

- Check that xen_phys_to_bus(map) returns the right dev_addr. As a
  reference, I know that on some arm32 platforms it wouldn't return the
  right value.

- Does the following patch fixes the issue for you?

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 87e6035..17c65fa 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -409,9 +409,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct 
page *page,
        if (map == SWIOTLB_MAP_ERROR)
                return DMA_ERROR_CODE;
 
+       dev_addr = xen_phys_to_bus(map);
        xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
                                        dev_addr, map & ~PAGE_MASK, size, dir, 
attrs);
-       dev_addr = xen_phys_to_bus(map);
 
        /*
         * Ensure that the address returned is DMA'ble

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