From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUk13-00013j-9I for qemu-devel@nongnu.org; Wed, 16 May 2012 15:36:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUk11-00061v-Hh for qemu-devel@nongnu.org; Wed, 16 May 2012 15:36:08 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:34617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUk11-00061W-BQ for qemu-devel@nongnu.org; Wed, 16 May 2012 15:36:07 -0400 Received: by pbbro12 with SMTP id ro12so1957971pbb.4 for ; Wed, 16 May 2012 12:36:05 -0700 (PDT) Message-ID: <4FB401A0.1060601@codemonkey.ws> Date: Wed, 16 May 2012 14:36:00 -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> <4FB2D291.1050003@codemonkey.ws> <1337123324.6727.101.camel@pasglop> <4FB2EDB2.5050305@codemonkey.ws> <1337128915.6727.112.camel@pasglop> <4FB2FAD0.603@codemonkey.ws> <1337131216.6727.116.camel@pasglop> In-Reply-To: <1337131216.6727.116.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 08:20 PM, Benjamin Herrenschmidt wrote: > On Tue, 2012-05-15 at 19:54 -0500, Anthony Liguori wrote: >> >> You certainly could do that but it may get a little weird dealing with the >> return path. You'd have to return something like -EWOULDBLOCK and make sure you >> handle that in the dispatch code appropriately. > > Hrm, our implementation of kvm_arch_handle_exit() always return "1" > after a hypercall, forcing kvm_cpu_exec() to return back to the thread > loop, so we should be ok to just set env->halted and return no ? I meant, if you wanted to have a synchronous hypercall function to dispatch, and then later call "hypercall_finish()", you would need a way to return an error in the synchronous hypercall to identify that something else would eventually call "hypercall_finish()." The sync hypercall would need to return something like -EWOULDBLOC. Setting env->halted=1 ought to be enough to delay returning to the guest although i'd have to go through the code to verify. Regards, Anthony Liguori > > Cheers, > Ben. > >