[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/6] PCI DMA API

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API
Date: Sun, 30 Mar 2008 14:02:25 -0500
User-agent: Thunderbird (X11/20080227)

Paul Brook wrote:
On Sunday 30 March 2008, Anthony Liguori wrote:
The entity processing the data shouldn't need to know or care how the translation is done. PhysIOVector should describe everything it need to know.

Okay, I'll update.

What could work is if the DMA API functions mapped PhysIOVector =>
PhysIOVector and then the network and block subsystems could operate on
a PhysIOVector.  I have patches that implement vector IO for net and
block but didn't want to include them in this series to keep things simple.

IMHO this is the only sane way to implement zero-copy.

This enables zero-copy IO to be preformed without introducing
assumptions of phys_ram_base.  This API is at the PCI device level to
enable support of per-device IOMMU remapping.
By my reading it *requires* bridges be zero-copy.  For big-endian targets
we need to ability to byteswap accesses.
You mean via ld/st_phys?

By whatever means the bridge deems necessary. The whole point of the DMA API is that you're transferring a block of data. The API allows intermediate busses to transform that data (and address) without the block handler needing to know or care.

With your current scheme a byteswapping bus has to allocate a single large buffer for the whole vector, even if the device then ends up copying unto a local buffer in small chunks.

Oh, I see now. The DMA API should have not just a mechanism to do bulk transfers but also provide an interface to do load/store's that could potentially be byte-swapped. I didn't realize buses did that.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]