From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTTDK-00025o-V6 for qemu-devel@nongnu.org; Wed, 10 Feb 2016 06:45:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTTDF-0001oe-Ve for qemu-devel@nongnu.org; Wed, 10 Feb 2016 06:45:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTTDF-0001n3-Pd for qemu-devel@nongnu.org; Wed, 10 Feb 2016 06:45:37 -0500 Date: Wed, 10 Feb 2016 12:45:31 +0100 From: Kevin Wolf Message-ID: <20160210114531.GA5474@noname.redhat.com> References: <20160209055506.8208.67.stgit@PASHA-ISP> <20160209055524.8208.16023.stgit@PASHA-ISP> <20160209102739.GB8554@noname.redhat.com> <001201d16330$6ce67e40$46b37ac0$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201d16330$6ce67e40$46b37ac0$@Dovgaluk@ispras.ru> Subject: Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/replay List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgalyuk Cc: edgar.iglesias@xilinx.com, peter.maydell@linaro.org, igor.rubinov@gmail.com, mark.burton@greensocs.com, real@ispras.ru, hines@cert.org, qemu-devel@nongnu.org, maria.klimushenkova@ispras.ru, stefanha@redhat.com, pbonzini@redhat.com, batuzovk@ispras.ru, alex.bennee@linaro.org, fred.konrad@greensocs.com Am 09.02.2016 um 12:52 hat Pavel Dovgalyuk geschrieben: > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > But even this doesn't feel completely right, because block drivers are > > already layered and there is no need to hardcode something optional (and > > rarely used) in the hot code path that could just be another layer. > > > > I assume that you know beforehand if you want to replay something, so > > requiring you to configure your block devices with a replay driver on > > top of the stack seems reasonable enough. > > I cannot use block drivers for this. When driver functions are used, QEMU > is already used coroutines (and probably started bottom halves). > Coroutines make execution non-deterministic. > That's why we have to intercept blk_aio_ functions, that are called > deterministically. What does "deterministic" mean in this context, i.e. what are your exact requirements? I don't think that coroutines introduce anything non-deterministic per se. Depending on what you mean by it, the block layer code paths in block.c may contain problematic code. The block layer uses bottom halves in some cases for request completion, but not until calling into the first driver (why would they be a problem?). What could happen is that a request is serialised and therefore delayed in some special configurations, which sounds a lot like what you wanted to avoid. Is there a writeup somewhere of the context in which this code is called and the rules that need to be considered for replay to work? Kevin