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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast
Date: Mon, 06 Jun 2011 15:09:19 +0200
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 Mnenhy/0.8.3 Thunderbird/3.1.10

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 special case, the existing functions are all mapped onto the new cpu_physical_memory_map_internal. I don't think this is in any way related to Avi's RAM API which is (mostly) for MMIO.

You're just trying to avoid having to handle map failures, right?

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 the current API does not allow.

The patch does not change virtio to do the split, but it is possible to do that. The reason I'm not doing the virtio change, is that I know mst has pending changes to virtio and I'd rather avoid the conflicts for now. However, for vmw_pvscsi I'm going to handle it using the new functions.

Paolo



reply via email to

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