From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBuLk-0003wO-AZ for qemu-devel@nongnu.org; Sun, 14 Dec 2008 12:01:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBuLh-0003vf-B6 for qemu-devel@nongnu.org; Sun, 14 Dec 2008 12:01:46 -0500 Received: from [199.232.76.173] (port=59258 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBuLh-0003vZ-5j for qemu-devel@nongnu.org; Sun, 14 Dec 2008 12:01:45 -0500 Received: from mx2.redhat.com ([66.187.237.31]:38988) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBuLg-0004Ue-Hm for qemu-devel@nongnu.org; Sun, 14 Dec 2008 12:01:44 -0500 Message-ID: <49453BF2.9070304@redhat.com> Date: Sun, 14 Dec 2008 19:01:38 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4942B841.6010900@codemonkey.ws> <20081213143944.GD30537@random.random> <4943E6F9.1050001@codemonkey.ws> <20081213165306.GE30537@random.random> <4944251D.8080109@codemonkey.ws> <20081214164751.GF30537@random.random> In-Reply-To: <20081214164751.GF30537@random.random> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: chrisw@redhat.com, kvm@vger.kernel.org, Gerd Hoffmann , qemu-devel@nongnu.org Andrea Arcangeli wrote: > To me map/unmap looks backwards. There's absolutely no point at all to > pretend that RAM isn't always mapped. Actually, with Xen, RAM may be unmapped due do Xen limitations when qemu runs on dom0 mode. But I think map/unmap makes sense even disregarding Xen: if we add memory hotunplug, we need to make sure we don't unplug memory that has pending dma operations on it. map/unmap gives us the opportunity to refcount memory slots. > The whole concept of having to map something is flawed, there's > nothing to map. At most you've to take a read lock to prevent future > memory hotplug to change the memory layout from under you, but the > concept of mapping has nothing to do with that. RAM is always mapped, > and mmio has to be emulated anyway so it's worthless to map it. > We can't get all dma to stop during hotunplug, since net rx operations are long-running (infinite if there is no activity on the link). IMO, we do want map/unmap, but this would be just a rename of can_dma and friends, and wouldn't have at this time any additional functionality. Bouncing has to happen where we have the ability to schedule the actual operation, and that's clearly not map/unmap. -- error compiling committee.c: too many arguments to function