From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6urO-0000fs-Bg for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6urM-0000et-IY for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:49 -0500 Received: from [199.232.76.173] (port=57661 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6urM-0000eo-9R for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:48 -0500 Received: from mx2.redhat.com ([66.187.237.31]:41478) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6urL-0003Fa-TP for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:33:48 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mAUMXgjq001076 for ; Sun, 30 Nov 2008 17:33:42 -0500 Date: Sun, 30 Nov 2008 23:33:40 +0100 From: Andrea Arcangeli Subject: Re: [Qemu-devel] [RFC 1/2] pci-dma-api-v1 Message-ID: <20081130223340.GG32172@random.random> References: <20081127123538.GC10348@random.random> <49319C86.8050408@redhat.com> <20081130172924.GB32172@random.random> <4932F72A.10201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4932F72A.10201@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org On Sun, Nov 30, 2008 at 10:27:22PM +0200, Avi Kivity wrote: > Oh okay. In that case it should be committed with DEBUG_BOUNCE enabled, > and that removed when we have proper aio *v. Exactly. But before this can be merged the emulation must be solved. Currently bdrv_aio_cancel can't work safe (with last patch it works safe only for drivers using the dma api). I guess one way is to move the emulation to the block-raw-posix.c layer. But in general I'm not really sure how to best handle this bdrv readv/writev in short-term merging terms. Perhaps we should just get rid of posix aio and add the real thing that will handle readv/writev as well even if that will surely take a bit more than some emulation form in block-raw-posix.c that could handle a safe cancellation for all read/write/readv/writev. > Overkill IMO (glibc likely caches mallocs), but can't hurt. Yes.