From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dptEA-0003PS-3D for qemu-devel@nongnu.org; Thu, 07 Sep 2017 05:36:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dptE5-0006XP-GW for qemu-devel@nongnu.org; Thu, 07 Sep 2017 05:36:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56600) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dptE5-0006XG-AA for qemu-devel@nongnu.org; Thu, 07 Sep 2017 05:35:57 -0400 Date: Thu, 7 Sep 2017 10:35:47 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20170907093546.GE2098@work-vm> References: <1503471071-2233-1-git-send-email-peterx@redhat.com> <20170906145043.GG15535@stefanha-x1.localdomain> <20170906151436.GF2215@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Xu , qemu-devel , Laurent Vivier , Fam Zheng , Juan Quintela , Markus Armbruster , Michael Roth , Paolo Bonzini * Stefan Hajnoczi (stefanha@gmail.com) wrote: > On Wed, Sep 6, 2017 at 4:14 PM, Dr. David Alan Gilbert > wrote: > > * Stefan Hajnoczi (stefanha@gmail.com) wrote: > >> On Wed, Aug 23, 2017 at 02:51:03PM +0800, Peter Xu wrote: > >> > The root problem is that, monitor commands are all handled in main > >> > loop thread now, no matter how many monitors we specify. And, if main > >> > loop thread hangs due to some reason, all monitors will be stuck. > >> > >> I see a larger issue with postcopy: existing QEMU code assumes that > >> guest memory access is instantaneous. > >> > >> Postcopy breaks this assumption and introduces blocking points that can > >> now take unbounded time. > >> > >> This problem isn't specific to the monitor. It can also happen to other > >> components in QEMU like the gdbstub. > >> > >> Do we need an asynchronous memory API? Synchronous memory access should > >> only be allowed in vcpu threads. > > > > It would probably be useful for gdbstub where the overhead of async > > doesn't matter; but doing that for all IO emulation is hard. > > Why is it hard? > > Memory access can be synchronous in the vcpu thread. That eliminates > a lot of code straight away. > > Anything using dma-helpers.c is already async. They just don't know > that the memory access part is being made async too :). Can you point me to some info on that ? > The remaining cases are virtio and some other devices. > > If you are worried about performance, the first rule is that async > memory access is only needed on the destination side when post-copy is > active. Maybe use setjmp to return from the signal handler and queue > a callback for when the page has been loaded. I'm not sure it's worth trying to be too clever at avoiding this; I see the fact that we're doing IO with the bql held as a more fundamental problem. Dave > Stefan -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK