On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> > In the common case, Dom0 also contains the PV backend drivers. Those
> > drivers may directly use the guest buffer in the DMA request (so a copy is
> > avoided). To avoid
On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> In the common case, Dom0 also contains the PV backend drivers. Those
> drivers may directly use the guest buffer in the DMA request (so a copy is
> avoided). To avoid using a bounce buffer too much, xen-swiotlb will find
> the host
Hi Christoph,
On 08/03/2019 15:23, Christoph Hellwig wrote:
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
the kernel point of
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
> On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
> on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
> the kernel point of view.
How can dma_addr_t on arm have value > 32-bit when
Hi Arnd,
On 3/5/19 8:16 AM, Arnd Bergmann wrote:
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
Hi Robin,
On 3/4/19 11:56 PM, Robin Murphy wrote:
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove
SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from
