On 06/06/2011 05:44 PM, Anthony Liguori wrote:
Not just that. If you had a memory block at say 1 GB - 2 GB, and another
at 2 GB - 3 GB, a DMA operation that crosses the two could be
implemented with cpu_physical_memory_map_fast; you would simply build a
two-element iovec in two steps, something
On 06/06/2011 08:09 AM, Paolo Bonzini wrote:
On 06/06/2011 02:56 PM, Anthony Liguori wrote:
Oh, the patch series basically died for me when I saw:
Avi> What performance benefit does this bring?
Paolo> Zero
:)
Especially given Avi's efforts to introduce a new RAM API, I don't want
yet anot
On 06/06/2011 02:56 PM, Anthony Liguori wrote:
Oh, the patch series basically died for me when I saw:
Avi> What performance benefit does this bring?
Paolo> Zero
:)
Especially given Avi's efforts to introduce a new RAM API, I don't want
yet another special case to handle.
This is not a sp
On 06/06/2011 07:27 AM, Paolo Bonzini wrote:
On 05/31/2011 11:16 AM, Paolo Bonzini wrote:
On 05/12/2011 04:51 PM, Paolo Bonzini wrote:
On 05/03/2011 06:49 PM, Paolo Bonzini wrote:
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, pro
On 05/31/2011 11:16 AM, Paolo Bonzini wrote:
On 05/12/2011 04:51 PM, Paolo Bonzini wrote:
On 05/03/2011 06:49 PM, Paolo Bonzini wrote:
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, provide a fast-path
function with the following p
On 05/12/2011 04:51 PM, Paolo Bonzini wrote:
On 05/03/2011 06:49 PM, Paolo Bonzini wrote:
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, provide a fast-path
function with the following properties:
1) it will never allocate a bounce
On 05/12/2011 05:32 PM, Avi Kivity wrote:
Out of curiosity, what performance benefit do you see?
Zero. :) Also because the only real change is in patch 4/4 (milkymist)
which I only compile-tested. In all other instances, using
cpu_physical_memory_map_fast is just to make it clear that we do
On 05/03/2011 07:49 PM, Paolo Bonzini wrote:
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, provide a fast-path
function with the following properties:
1) it will never allocate a bounce buffer
2) it can be used for read-modify-wr
On 05/03/2011 06:49 PM, Paolo Bonzini wrote:
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, provide a fast-path
function with the following properties:
1) it will never allocate a bounce buffer
2) it can be used for read-modify-wr
Paravirtualized devices (and also some real devices) can assume they
are going to access RAM. For this reason, provide a fast-path
function with the following properties:
1) it will never allocate a bounce buffer
2) it can be used for read-modify-write operations
3) unlike qemu_get_ram_ptr, it
10 matches
Mail list logo
