From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ0jE-0007i6-VK for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:19:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJ0jC-0005It-8I for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:19:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ0jC-0005Ii-39 for qemu-devel@nongnu.org; Tue, 12 Jan 2016 10:19:22 -0500 References: <87r3hx6040.fsf@linaro.org> <5695081C.1070101@greensocs.com> <87vb6yde8g.fsf@linaro.org> From: Paolo Bonzini Message-ID: <5695196E.70902@redhat.com> Date: Tue, 12 Jan 2016 16:19:10 +0100 MIME-Version: 1.0 In-Reply-To: <87vb6yde8g.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] MTTCG sync-up call today? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= , KONRAD Frederic Cc: mttcg@greensocs.com, Mark Burton , Paolo Bonzini , QEMU Developers , alvise rigo On 12/01/2016 16:11, Alex Benn=C3=A9e wrote: > > Sorry for the late answer, I find some time to take a look at it. > > > > Seems you were right I fixed the exit issue and it seems it was one o= f > > the problem. > > I think we must double check how we use cpu->exit_request as Paolo > > removed SIG_IPI to exit the CPU. > > > > I found one additional issue and it seems booting well right now. > > The other thing that needs cleaning up is the tcg_current_cpu and > current_cpu. I suspect the former should go and the restrictions on the > later be loosend so the TLS current_cpu is available to deferred tasks. Yes, you can make TLS current_cpu always non-NULL for multi-threaded TCG. tcg_current_cpu definitely should go, it doesn't make sense if you have multiple threads. > The thing I'm currently looking at is what happens when something like = a > virtio completes in a non-CPU thread. It should just work. It will cause a cpu_interrupt under the BQL, and that sets cpu->interrupt_request. The code that modifies cpu->interrupt_request in the VCPU thread also runs under the BQL. Paolo