From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTbyY-0008V5-U0 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:44:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTbyW-0004tL-Vh for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:44:22 -0400 Received: from mail-px0-f174.google.com ([209.85.212.174]:57316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTbyW-0004sx-Fi for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:44:20 -0400 Received: by pxi15 with SMTP id 15so930594pxi.33 for ; Mon, 06 Jun 2011 08:44:18 -0700 (PDT) Message-ID: <4DECF5CF.5040405@codemonkey.ws> Date: Mon, 06 Jun 2011 10:44:15 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1304441374-27314-1-git-send-email-pbonzini@redhat.com> <4DCBF3F2.6060702@redhat.com> <4DE4B1F1.5030201@redhat.com> <4DECC7A6.7030506@redhat.com> <4DECCE94.1000904@codemonkey.ws> <4DECD17F.2040307@redhat.com> In-Reply-To: <4DECD17F.2040307@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org 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 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. You cannot assume RAM blocks are contiguous. This has nothing to do with PV or not PV but how the RAM API works today. > > 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. Virtio can handle all of this today because it uses cpu_physical_memory_rw for ring access and then calls map for SG elements. SG elements are usually 4k so it's never really an issue to get a partial mapping. We could be more robust about it but in practice, it's not a problem. Regards, Anthony Liguori > > Paolo >