From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgvWk-0000vU-Pv for qemu-devel@nongnu.org; Fri, 07 Dec 2012 05:51:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgvWg-0007VF-RS for qemu-devel@nongnu.org; Fri, 07 Dec 2012 05:51:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgvWg-0007Uz-Je for qemu-devel@nongnu.org; Fri, 07 Dec 2012 05:51:26 -0500 Message-ID: <50C1CA26.2040605@redhat.com> Date: Fri, 07 Dec 2012 11:51:18 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1354740430-22452-1-git-send-email-stefanha@redhat.com> <1354740430-22452-11-git-send-email-stefanha@redhat.com> <50C04ADB.9040402@redhat.com> <20121207060608.GB5244@stefanha-thinkpad.redhat.com> In-Reply-To: <20121207060608.GB5244@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 10/11] dataplane: add virtio-blk data plane code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Blue Swirl , khoa@us.ibm.com, asias@redhat.com Il 07/12/2012 07:06, Stefan Hajnoczi ha scritto: > BTW I should go into slightly more detail about why I stopped short of > implementing the notify+join approach. > > notify+join means stopping the event loop and data plane thread so > that the caller is sure that virtio-blk-data-plane is quiesced. > > Unfortunately this doesn't map nicely to bdrv_drain_all() where the > caller has the global mutex, quiesces I/O, and then performs a critical > operation. I/O resumes after the caller returns or releases the global > mutex: > > bdrv_drain_all(); > critical_operation(); > return; > /* now it's okay to process I/O again */ > > We cannot use notify+join here because bdrv_drain_all() would stop the > data plane thread but nothing restarts it! That's true. The solution here for AioContext would be to run the event loop in the context of the thread that is calling bdrv_drain_all(). But you do not need bdrv_drain_all() right now, and the event loop would be rewritten anyway to use AioContext, so the lack of "resume" is not a problem for now IMHO. > Perhaps we'd need a "resume" call after the critical operation so that > the data plane thread is restarted - but this sounds invasive and is a > departure from how existing I/O and emulated devices work. The problem was more about the possible race in the draining of requests, but it's okay to tackle it later. Paolo