From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYvXy-0005J9-7N for qemu-devel@nongnu.org; Thu, 25 Feb 2016 08:01:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYvXs-0000Sj-Lg for qemu-devel@nongnu.org; Thu, 25 Feb 2016 08:01:34 -0500 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:35376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYvXs-0000Rm-EG for qemu-devel@nongnu.org; Thu, 25 Feb 2016 08:01:28 -0500 Received: by mail-wm0-x242.google.com with SMTP id g62so3334863wme.2 for ; Thu, 25 Feb 2016 05:01:28 -0800 (PST) Sender: Paolo Bonzini References: <1450284917-10508-1-git-send-email-apyrgio@arrikto.com> <1450284917-10508-2-git-send-email-apyrgio@arrikto.com> <56BC6DC0.4070204@redhat.com> <56C70168.2050408@arrikto.com> <56CAE64B.4070608@redhat.com> <56CED32C.6020001@arrikto.com> <56CED5CD.1070400@redhat.com> <56CEE344.9010702@arrikto.com> From: Paolo Bonzini Message-ID: <56CEFB23.7090108@redhat.com> Date: Thu, 25 Feb 2016 14:01:23 +0100 MIME-Version: 1.0 In-Reply-To: <56CEE344.9010702@arrikto.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/9] dma-helpers: Expose the sg mapping logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Pyrgiotis , Fam Zheng , Kevin Wolf , qemu-devel On 25/02/2016 12:19, Alex Pyrgiotis wrote: >> The patch could first introduce address_space_map_direct that never uses >> the bounce buffer. dma-helpers.c can call address_space_map_direct and, >> if it fails, proceed to allocate (and fill if writing to the device) a >> bounce buffer. > > You mean that address_space_map_direct() is a copy of the > address_space_map() code, minus the bounce buffer part which will be > handled in dma-helpers.c? If so, I agree. Yes. In particular minus the: if (!memory_access_is_direct(mr, is_write)) part, hence the name. :) If direct access isn't possible, address_space_map_direct would always return NULL, like address_space_map does when bounce.in_use is already true. > Also, the buffer should be removed from address_space_unmap. Right, though only after address_space_map_direct is renamed to address_space_map. That's also the point where cpu_register_map_client disappears, and other parts of dma-helpers.c too such as the bottom half. >> Since the QEMUSGList is mapped and unmapped >> beginning-to-end, you can just use a FIFO queue. The FIFO queue stores >> a (QEMUSGList, buffer) tuple. > > I suppose that this queue is stored in the dbs structure of dma-helpers? > If so, I agree. Yes. >> Then, once the bounce buffer is implemented within dma-helpers.c, you >> remove address_space_map and rename address_space_map_direct to >> address_space_map. cpu_register_map_client goes away. > > What about the other users of address_space_map()? Is the bounce buffer > used only for DMA operations? If so, I agree. Else, we need a fallback. Other users usually fail if address_space_map cannot return a mapping as big as requested. They also do not use cpu_register_map_client. Both shortcomings mean that in practice they do not support the bounce buffer. Paolo