From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBESb-0005b5-1p for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:18:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBESa-0005aO-7v for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:18:04 -0500 Received: from [199.232.76.173] (port=47371 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBESa-0005aJ-64 for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:18:04 -0500 Received: from yw-out-1718.google.com ([74.125.46.152]:54303) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBESZ-0008DS-QF for qemu-devel@nongnu.org; Fri, 12 Dec 2008 15:18:03 -0500 Received: by yw-out-1718.google.com with SMTP id 6so748625ywa.82 for ; Fri, 12 Dec 2008 12:18:02 -0800 (PST) Message-ID: <4942C6F7.2080609@codemonkey.ws> Date: Fri, 12 Dec 2008 14:17:59 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool References: <49400F69.8080707@codemonkey.ws> <20081210190810.GG18814@random.random> <20081212142435.GL6809@random.random> <494276CD.6060904@codemonkey.ws> <20081212154418.GM6809@random.random> <49429629.20309@codemonkey.ws> <20081212170916.GO6809@random.random> <49429EA3.8070008@codemonkey.ws> <20081212175213.GP6809@random.random> <4942AAD6.1090408@codemonkey.ws> <20081212182634.GQ6809@random.random> <4942C5C1.9080107@redhat.com> In-Reply-To: <4942C5C1.9080107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Andrea Arcangeli , qemu-devel@nongnu.org, kvm-devel Gerd Hoffmann wrote: > Andrea Arcangeli wrote: > >> On Fri, Dec 12, 2008 at 12:17:58PM -0600, Anthony Liguori wrote: >> >>> You assume that anything using bdrv_aio_readv/writev will be going through >>> a DMA API. This isn't a safe assumption. >>> >> Well it's obviously a safe assumption right now... ;) >> > > Well, the xen block backend in my xen patch queue calls bdrv_* directly > right now. Dunno whenever it is possible/useful to fit the grant table > stuff into the upcoming dma api somehow. > I don't know about grant table references b/c that's really foreign memory. But this is a good argument against the DMA as it stands, b/c you may be handing foreign memory to bdrv_aio_readv/writev. A big reason for the map/unmap lock/unlock abstraction though would be the qemu-dm map cache. I think you could use it to pretty reasonably integrate the map cache which I know I've previously could never be done :-) Regards, Anthony Liguori > cheers, > Gerd > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >