qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast
Date: Thu, 12 May 2011 18:32:20 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10

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-write operations

3) unlike qemu_get_ram_ptr, it is safe because it recognizes "short" blocks

Patches 3 and 4 use this function for virtio devices and the milkymist
GPU.  The latter is only compile-tested.

Another function checks if it is possible to split a contiguous physical
address range into multiple subranges, all of which use the fast path.
I will introduce later a use for this function.


Out of curiosity, what performance benefit do you see?

For relatively constant mappings (like the ring) we can cache the mapping in structure and invalidate it when the memory map changes (using, say, rcu). That doesn't work for the actual buffers, or for indirect mappings.

--
error compiling committee.c: too many arguments to function




reply via email to

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