From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTc9l-0003Lp-68 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:55:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTc9i-0007Kq-Nk for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:55:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTc9i-0007Kd-7Y for qemu-devel@nongnu.org; Mon, 06 Jun 2011 11:55:54 -0400 Message-ID: <4DECF886.5090808@redhat.com> Date: Mon, 06 Jun 2011 17:55:50 +0200 From: Paolo Bonzini 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> <4DECF5CF.5040405@codemonkey.ws> In-Reply-To: <4DECF5CF.5040405@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org 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 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. That's exactly why I said a *two-element* iovec. > 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. I know in practice it's not a problem, but I dislike not having an API that can deal with it even in theory. For vmw_pvscsi it's like 5 lines of code to allow it. Paolo