From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support Date: Thu, 15 Jul 2010 11:33:14 +0100 Message-ID: <201007151133.14493.paul@codesourcery.com> References: <1279086307-9596-1-git-send-email-eduard.munteanu@linux360.ro> <201007142113.44913.paul@codesourcery.com> <4C3E2C2E.70507@codemonkey.ws> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Joerg Roedel , avi@redhat.com, kvm@vger.kernel.org, "Eduard - Gabriel Munteanu" To: Anthony Liguori Return-path: Received: from mail.codesourcery.com ([38.113.113.100]:52522 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933012Ab0GOKdQ (ORCPT ); Thu, 15 Jul 2010 06:33:16 -0400 In-Reply-To: <4C3E2C2E.70507@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: > > 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 Paul