All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Paul Brook <paul@codesourcery.com>
Cc: kvm-devel@lists.sourceforge.net,
	Marcelo Tosatti <marcelo@kvack.org>,
	qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API
Date: Sun, 30 Mar 2008 14:02:25 -0500	[thread overview]
Message-ID: <47EFE3C1.1000205@us.ibm.com> (raw)
In-Reply-To: <200803301919.54780.paul@codesourcery.com>

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.

Regards,

Anthony Liguori

> Paul
>   


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <aliguori@us.ibm.com>
To: Paul Brook <paul@codesourcery.com>
Cc: kvm-devel@lists.sourceforge.net,
	Marcelo Tosatti <marcelo@kvack.org>,
	qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API
Date: Sun, 30 Mar 2008 14:02:25 -0500	[thread overview]
Message-ID: <47EFE3C1.1000205@us.ibm.com> (raw)
In-Reply-To: <200803301919.54780.paul@codesourcery.com>

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.

Regards,

Anthony Liguori

> Paul
>   

  reply	other threads:[~2008-03-30 19:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-29 21:55 [PATCH 1/6] Use ram_addr_t for cpu_get_physical_page_desc Anthony Liguori
2008-03-29 21:55 ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 2/6] PCI DMA API Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30  7:06   ` Blue Swirl
2008-03-30  7:06     ` Blue Swirl
2008-03-30 14:44     ` Anthony Liguori
2008-03-30 14:44       ` Anthony Liguori
2008-03-30 14:49       ` Avi Kivity
2008-03-30 14:49         ` Avi Kivity
2008-03-30 14:56         ` Anthony Liguori
2008-03-30 14:56           ` [kvm-devel] " Anthony Liguori
2008-03-30 14:58       ` Blue Swirl
2008-03-30 14:58         ` Blue Swirl
2008-03-30 15:11         ` Anthony Liguori
2008-03-30 15:11           ` Anthony Liguori
2008-03-30 10:18   ` Paul Brook
2008-03-30 10:18     ` Paul Brook
2008-03-30 14:42     ` Anthony Liguori
2008-03-30 14:42       ` Anthony Liguori
2008-03-30 18:19       ` Paul Brook
2008-03-30 18:19         ` Paul Brook
2008-03-30 19:02         ` Anthony Liguori [this message]
2008-03-30 19:02           ` Anthony Liguori
2008-03-30 10:25   ` Avi Kivity
2008-03-30 10:25     ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
2008-03-30 14:49     ` Anthony Liguori
2008-03-30 14:49       ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 3/6] virtio for QEMU Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30 17:25   ` Dor Laor
2008-03-30 17:25     ` Dor Laor
2008-03-30 22:59     ` Anthony Liguori
2008-03-30 22:59       ` [kvm-devel] " Anthony Liguori
2008-04-05  3:09     ` Anthony Liguori
2008-04-05  3:09       ` Anthony Liguori
2008-03-29 21:55 ` [PATCH 4/6] virtio network driver Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30 10:27   ` Paul Brook
2008-03-30 10:27     ` Paul Brook
2008-03-30 14:47     ` Anthony Liguori
2008-03-30 14:47       ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 5/6] virtio block driver Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:56 ` [PATCH 6/6] virtio balloon driver Anthony Liguori
2008-03-29 21:56   ` [Qemu-devel] " Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47EFE3C1.1000205@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=aurelien@aurel32.net \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=marcelo@kvack.org \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.