From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53800 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZNm0-0002a0-Qj for qemu-devel@nongnu.org; Thu, 15 Jul 2010 08:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZNlv-0002mJ-Gu for qemu-devel@nongnu.org; Thu, 15 Jul 2010 08:42:44 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:39943) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZNlv-0002mA-DW for qemu-devel@nongnu.org; Thu, 15 Jul 2010 08:42:39 -0400 Received: by qwf6 with SMTP id 6so222829qwf.4 for ; Thu, 15 Jul 2010 05:42:38 -0700 (PDT) Message-ID: <4C3F0242.90005@codemonkey.ws> Date: Thu, 15 Jul 2010 07:42:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support References: <1279086307-9596-1-git-send-email-eduard.munteanu@linux360.ro> <201007142113.44913.paul@codesourcery.com> <4C3E2C2E.70507@codemonkey.ws> <201007151133.14493.paul@codesourcery.com> In-Reply-To: <201007151133.14493.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Joerg Roedel , Eduard - Gabriel Munteanu , qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com On 07/15/2010 05:33 AM, Paul Brook wrote: >>> Depending how the we decide to handle IOMMU invalidation, it may also be >>> necessary to augment the memory_map API to allow the system to request a >>> mapping be revoked. However this issue is not specific to the IOMMU >>> implementation. Such bugs are already present on any system that allows >>> dynamic reconfiguration of the address space, e.g. by changing PCI BARs. >>> >> That's why the memory_map API today does not allow mappings to persist >> after trips back to the main loop. >> > Sure it does. If you can't combine zero-copy memory access with asynchronous > IO then IMO it's fairly useless. See e.g. dma-helpers.c > DMA's a very special case. DMA is performed asynchronously to the execution of the CPU so you generally can't make any guarantees about what state the transaction is in until it's completed. That gives us a fair bit of wiggle room when dealing with a DMA operation to a region of physical memory where the physical memory mapping is altered in some way during the transaction. However, that is not true in the general case. Regards, Anthony Liguori > Paul >