From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPKcs-0007nH-53 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 12:42:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPKcr-0007ms-Pm for qemu-devel@nongnu.org; Tue, 20 Jan 2009 12:42:57 -0500 Received: from [199.232.76.173] (port=48724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPKcr-0007ml-48 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 12:42:57 -0500 Received: from mx2.redhat.com ([66.187.237.31]:45131) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPKcq-00066s-II for qemu-devel@nongnu.org; Tue, 20 Jan 2009 12:42:56 -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 n0KHgtq9021545 for ; Tue, 20 Jan 2009 12:42:55 -0500 Message-ID: <49760D1C.3020202@redhat.com> Date: Tue, 20 Jan 2009 19:42:52 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <4974943B.4020507@redhat.com> <18804.44271.868488.32192@mariner.uk.xensource.com> <4974B82F.9020805@redhat.com> <20090119182502.GA2080@shareable.org> <4974C9BA.1050803@redhat.com> <18805.58460.230350.875145@mariner.uk.xensource.com> In-Reply-To: <18805.58460.230350.875145@mariner.uk.xensource.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: qemu-devel@nongnu.org Ian Jackson wrote: > Avi Kivity writes ("Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API"): > >> The devices we're talking about here don't have a DMA count register. >> > > Which devices ? All devices ever that want to do zero-copy DMA into > the guest ? > IDE, scsi, virtio-blk, virtio-net, e1000, maybe a few more. >> They are passed scatter-gather lists, and I don't think they make >> guarantees about the order in which they're accessed. >> > > Many devices will be able to make such promises. > If they do, and if guests actually depend on these promises, then we will not use the new API until someone is sufficiently motivated to send a patch to enable it. >> This DMA will be into RAM, not mmio. >> > > As previously discussed, we might be using bounce buffers even for > RAM, depending on the execution model. You said earlier: > > Try it out. I'm sure it will work just fine (if incredibly slowly, > unless you provide multiple bounce buffers). > > but here is an example from Jamie of a situation where it won't work > right. > Framebuffers? Those are RAM. USB webcams? These can't be interrupted by SIGINT. Are you saying a guest depends on an O_DIRECT USB transfer not affecting memory when a USB cable is pulled out? >> We don't have a reliable amount to pass. >> > > A device which _really_ doesn't have a reliable amount to pass, and > which is entitled to scribble all over the RAM it was to DMA to even > if it does only a partial transfer, can simply pass the total transfer > length. That would be no different to your proposal. > I'm suggesting we do that unconditionally (as my patch does) and only add that complexity when we know it's needed for certain. -- error compiling committee.c: too many arguments to function