From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Fm4-0004dd-Sy for qemu-devel@nongnu.org; Wed, 16 Dec 2015 12:22:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9Flz-00057C-TS for qemu-devel@nongnu.org; Wed, 16 Dec 2015 12:22:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Flz-00056w-Nk for qemu-devel@nongnu.org; Wed, 16 Dec 2015 12:21:55 -0500 References: <87zixafh89.fsf@linaro.org> From: Paolo Bonzini Message-ID: <56719DAC.2030000@redhat.com> Date: Wed, 16 Dec 2015 18:21:48 +0100 MIME-Version: 1.0 In-Reply-To: <87zixafh89.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Rationalising exit_request, cpu->exit_request and tcg_exit_req? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= , QEMU Devel , mttcg@greensocs.com, mark.burton@greensocs.com, fred.konrad@greensocs.com, Richard Henderson , Peter Crosthwaite , Peter Maydell On 16/12/2015 18:14, Alex Benn=C3=A9e wrote: >=20 > While looking at Fred's current MTTCG WIP branch I ran into a problem > where: >=20 > - async_safe_work_pending() was true > - this triggered setting cpu->exit_request > - however we never left tcg_exec_all() > - because the global exit_request wasn't set > - hence qemu_tcg_wait_io_event() never drained the async work queue exit_request should disappear with MTTCG. It should only have cpu->tcg_exit_req and cpu->exit_request. > While trying to understand why we have both a cpu and a global > exit_request I then discovered there is also cpu->tcg_exit_req which is > the actual variable the TCG examines. This leads to sequences like: > This seems to me to be slightly insane as we now have 3 variables that > struggle to be kept in sync. Could all this not be rationalised into a > single variable or am I missing a subtly in their different semantics? They do. cpu->tcg_exit_req is the one that is set from generated code. It is set if you do not have to exit cpu_exec. cpu->exit_request and exit_request are both necessary, in order to synchronize exits with the setting of tcg_current_cpu. Again, this is only needed in single-threaded TCG, because MTTCG gets rid of tcg_current_cpu. It's documented here: http://article.gmane.org/gmane.comp.emulators.qemu/357210. > I don't know if there is clean-up that can happen in master or if this > all needs to be done in the mttcg work but would it make sense just to > keep cpu->exit_request, Yes, and it's actually necessary. :) > I did have a brief look at the KVM side of the code and it only seems t= o > reference cpu->exit_request so I think the rest of this is a TCG > problem. Yes. With MTTCG you still need cpu->tcg_exit_req because you still have something like KVM's kernel- and userspace-vmexits. In TCG the lightweight exits are those that do not leave cpu_exec. Those only set cpu->tcg_exit_req. Paolo