From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUPpl-0004O7-QO for qemu-devel@nongnu.org; Tue, 15 May 2012 18:03:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUPpk-0007pb-3N for qemu-devel@nongnu.org; Tue, 15 May 2012 18:03:09 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:33090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUPpj-0007oy-Sp for qemu-devel@nongnu.org; Tue, 15 May 2012 18:03:08 -0400 Received: by dadv2 with SMTP id v2so123847dad.4 for ; Tue, 15 May 2012 15:03:05 -0700 (PDT) Message-ID: <4FB2D291.1050003@codemonkey.ws> Date: Tue, 15 May 2012 17:02:57 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1336625347-10169-1-git-send-email-benh@kernel.crashing.org> <1336625347-10169-9-git-send-email-benh@kernel.crashing.org> <4FB1A80C.1010103@codemonkey.ws> <20120515014204.GE30229@truffala.fritz.box> <4FB1B95A.20209@codemonkey.ws> <1337049166.6727.32.camel@pasglop> <4FB1C480.1030408@codemonkey.ws> <1337050942.6727.40.camel@pasglop> <4FB26212.5050409@codemonkey.ws> <1337118943.6727.93.camel@pasglop> In-Reply-To: <1337118943.6727.93.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 08/13] iommu: Introduce IOMMU emulation infrastructure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Alex Williamson , Richard Henderson , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Eduard - Gabriel Munteanu On 05/15/2012 04:55 PM, Benjamin Herrenschmidt wrote: > On Tue, 2012-05-15 at 09:02 -0500, Anthony Liguori wrote: > >> I think the crux of your argument is that upon a change to the translation >> table, the operation acts as a barrier such that the exact moment it returns, >> you're guaranteed that no DMAs are in flight with the old translation mapping. > > Not when the translation is changed in memory but whenever the > translation cache are invalidated or whatever other mechanism the HW > provides to do that synchronization. On PAPR, this guarantee is provided > by the H_PUT_TCE hypervisor call which we use to manipulate > translations. So this is from the VT-d spec: "6.2.1 Register Based Invalidation Interface The register based invalidations provides a synchronous hardware interface for invalidations. Software is expected to write to the IOTLB registers to submit invalidation command and may poll on these registers to check for invalidation completion. For optimal performance, hardware implementations are recommended to complete an invalidation request with minimal latency" This makes perfect sense. You write to an MMIO location to request invalidation and then *poll* on a separate register for completion. It's not a single MMIO operation that has an indefinitely return duration. Regards, Anthony Liguori