From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sun, 14 Dec 2008 19:01:38 +0200 Message-ID: <49453BF2.9070304@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org, chrisw@redhat.com To: Andrea Arcangeli Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57852 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbYLNRBp (ORCPT ); Sun, 14 Dec 2008 12:01:45 -0500 In-Reply-To: <20081214164751.GF30537@random.random> Sender: kvm-owner@vger.kernel.org List-ID: 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