From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZMX-0004Sh-8t for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:56:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTZMW-00013O-04 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:56:57 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:34484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZMV-00013C-LZ for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:56:55 -0400 Received: by gyg4 with SMTP id 4so1734745gyg.4 for ; Mon, 06 Jun 2011 05:56:54 -0700 (PDT) Message-ID: <4DECCE94.1000904@codemonkey.ws> Date: Mon, 06 Jun 2011 07:56:52 -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> In-Reply-To: <4DECC7A6.7030506@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 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, 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. >>>> >>>> Paolo Bonzini (4): >>>> exec: extract cpu_physical_memory_map_internal >>>> exec: introduce cpu_physical_memory_map_fast and >>>> cpu_physical_memory_map_check >>>> virtio: use cpu_physical_memory_map_fast >>>> milkymist: use cpu_physical_memory_map_fast >>>> >>>> cpu-common.h | 4 ++ >>>> exec.c | 108 +++++++++++++++++++++++++++++++++++++------------- >>>> hw/milkymist-tmu2.c | 39 ++++++++++-------- >>>> hw/vhost.c | 10 ++-- >>>> hw/virtio.c | 2 +- >>>> 5 files changed, 111 insertions(+), 52 deletions(-) >>>> >>> >>> Ping? >> >> Ping^2? > > Ping^3? 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. You're just trying to avoid having to handle map failures, right? So it's not really cpu_physical_memory_map_fast, it's really cpu_physical_memory_map_simple? I'd prefer that a device just treat failures as fatal vs. using a new API. Regards, Anthony Liguori > Paolo >