From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUSJm-0003Qp-Cn for qemu-devel@nongnu.org; Tue, 15 May 2012 20:42:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUSJk-0001BH-DW for qemu-devel@nongnu.org; Tue, 15 May 2012 20:42:17 -0400 Received: from gate.crashing.org ([63.228.1.57]:47911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUSJk-0001Av-4Q for qemu-devel@nongnu.org; Tue, 15 May 2012 20:42:16 -0400 Message-ID: <1337128915.6727.112.camel@pasglop> From: Benjamin Herrenschmidt Date: Wed, 16 May 2012 10:41:55 +1000 In-Reply-To: <4FB2EDB2.5050305@codemonkey.ws> 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> <4FB2D291.1050003@codemonkey.ws> <1337123324.6727.101.camel@pasglop> <4FB2EDB2.5050305@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 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: Anthony Liguori Cc: Alex Williamson , Richard Henderson , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Eduard - Gabriel Munteanu On Tue, 2012-05-15 at 18:58 -0500, Anthony Liguori wrote: > Even ancient PIO devices really don't block indefinitely. > > > In our case (TCEs) it's a hypervisor call, not an MMIO op, so to some > > extent it's even more likely to do "blocking" things. > > Yes, so I think the right thing to do is not model hypercalls for sPAPR as > synchronous calls but rather as asynchronous calls. Obviously, simply ones can > use a synchronous implementation... > > This is a matter of setting hlt=1 before dispatching the hypercall and passing a > continuation to the call that when executed, prepare the CPUState for the > hypercall return and then set hlt=0 to resume the CPU. Is there any reason not to set that hlt after the dispatch ? IE. from within the hypercall, for the very few that want to do asynchronous completion, do something like spapr_hcall_suspend() before returning ? > > It would have been possible to implement a "busy" return status with the > > guest having to try again, unfortunately that's not how Linux has > > implemented it, so we are stuck with the current semantics. > > > > Now, if you think that dropping the lock isn't good, what do you reckon > > I should do ? > > Add a reference count to dma map calls and a flush_pending flag. If > flush_pending && ref > 0, return NULL for all map calls. > > Decrement ref on unmap and if ref = 0 and flush_pending, clear flush_pending. > You could add a flush_notifier too for this event. > > dma_flush() sets flush_pending if ref > 0. Your TCE flush hypercall would > register for flush notifications and squirrel away the hypercall completion > continuation. Ok, I'll look into it, thanks. Any good example to look at for how that continuation stuff works ? > VT-d actually has a concept of a invalidation completion queue which delivers > interrupt based notification of invalidation completion events. The above > flush_notify would be the natural way to support this since in this case, there > is no VCPU event that's directly involved in the completion event. Cheers, Ben. > Regards, > > Anthony Liguori > > > Cheers, > > Ben. > > > >