From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0psR-0007jc-SP for qemu-devel@nongnu.org; Fri, 14 Sep 2018 11:19:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0psM-0006Ns-Sc for qemu-devel@nongnu.org; Fri, 14 Sep 2018 11:19:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46052) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0psM-0006M2-Ju for qemu-devel@nongnu.org; Fri, 14 Sep 2018 11:19:18 -0400 References: <20180912081747.3228.21861.stgit@pasha-VirtualBox> <20180912081950.3228.68987.stgit@pasha-VirtualBox> <002101d44bee$9edf9720$dc9ec560$@ru> From: Paolo Bonzini Message-ID: Date: Fri, 14 Sep 2018 17:19:11 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 21/25] replay: replay BH for IDE trim operation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Pavel Dovgalyuk , 'Pavel Dovgalyuk' , qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, war2jordan@live.com, quintela@redhat.com, ciro.santilli@gmail.com, jasowang@redhat.com, crosthwaite.peter@gmail.com, zuban32s@gmail.com, armbru@redhat.com, maria.klimushenkova@ispras.ru, mst@redhat.com, kraxel@redhat.com, boost.lists@gmail.com, thomas.dullien@googlemail.com, mreitz@redhat.com, alex.bennee@linaro.org, dgilbert@redhat.com, rth@twiddle.net On 14/09/2018 16:00, John Snow wrote: >> Maybe not. We can hardly analyze all peripheral devices code and fix all the calls. >> But I think we can improve that patch and at least look through ide core to fix other calls. >> >> Pavel Dovgalyuk >> > It just seems odd that if you're working on a replay mechanism that > requires you to intercept my QEMU API calls that you're only changing a > trim callback. You need it only here because the block layer is already calling replay_bh_schedule_event (actually replay_bh_schedule_oneshot_event after patch 22 of this series) on reads and writes. Paolo > I'd kind of expect that you don't need to intercept any, unless these > are legacy calls that I shouldn't be making at all and you have a more > generic intercept somewhere deeper in the codebase. > > In that case, I really ought to hustle off of my use of legacy calls. > > What are the criteria for things you need to intercept/wrap?