|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one
On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> > The other issue I heard about was some root file system corruptions after
> > two or three re-boots we haven't observed in the native Linux case. The
> > plan was to do some further analysis, first, before we blame Xen regarding
> > this, though.
> >
> > As mentioned, Pooya will have the details and correct me if I'm totally
> > wrong here ;)
> >
>
> 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?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |