From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvNcJ-0007Qb-Op for qemu-devel@nongnu.org; Tue, 04 Apr 2017 08:31:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cvNcG-00087Q-Jr for qemu-devel@nongnu.org; Tue, 04 Apr 2017 08:31:23 -0400 Received: from mail-wr0-x22e.google.com ([2a00:1450:400c:c0c::22e]:34332) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cvNcG-00085k-DP for qemu-devel@nongnu.org; Tue, 04 Apr 2017 08:31:20 -0400 Received: by mail-wr0-x22e.google.com with SMTP id t20so8371905wra.1 for ; Tue, 04 Apr 2017 05:31:20 -0700 (PDT) References: <20170403124524.10824-1-alex.bennee@linaro.org> <20170403124524.10824-8-alex.bennee@linaro.org> <000201d2ad05$e28626d0$a7927470$@ru> <8760ikblf7.fsf@linaro.org> <874ly4bgbu.fsf@linaro.org> <3c4f3f42-3b33-8e0a-b3f4-0963670b47de@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <3c4f3f42-3b33-8e0a-b3f4-0963670b47de@redhat.com> Date: Tue, 04 Apr 2017 13:31:17 +0100 Message-ID: <8737dobbhm.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH v1 7/9] cpus: move icount preparation out of tcg_exec_cpu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Pavel Dovgalyuk , rth@twiddle.net, peter.maydell@linaro.org, qemu-devel@nongnu.org, mttcg@listserver.greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org, bobby.prani@gmail.com, nikunj@linux.vnet.ibm.com, 'Peter Crosthwaite' Paolo Bonzini writes: > On 04/04/2017 12:46, Alex Bennée wrote: >>> In theory the main-loop should be sequenced before or after vCPU events >>> because of the BQL. I'm not sure why this is not currently the case. >> >> It seems cpu_handle_exception doesn't take the BQL until >> replay_exception() has done its thing. This is fixable but the function >> is a mess so I'm trying to neaten that up first. > > Long term neither cpu_handle_exception nor cpu_handle_interrupt need the > BQL at all. Well for record/replay they might. Otherwise we end up moving the record stream on even though a checkpoint might be being written by the main-loop. As far as the cc->do_interrupt() stuff is concerned it will be guest dependant because you could end up in device emulation code down this path which must be protected by the BQL - the arm_gic code being a good example. > > Paolo -- Alex Bennée