From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPqMf-0004G4-91 for qemu-devel@nongnu.org; Wed, 10 Apr 2013 04:26:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPqMc-0004IP-AJ for qemu-devel@nongnu.org; Wed, 10 Apr 2013 04:26:45 -0400 Message-ID: <5165222E.4020606@adacore.com> Date: Wed, 10 Apr 2013 10:26:22 +0200 From: Fabien Chouteau MIME-Version: 1.0 References: <1361367811-13288-1-git-send-email-pbonzini@redhat.com> <1361367811-13288-2-git-send-email-pbonzini@redhat.com> <5125D10A.5010609@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] win32: do not set CPU affinity List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roy Tam Cc: Paolo Bonzini , qemu-stable@nongnu.org, jacob.kroon@gmail.com, qemu-devel@nongnu.org, Stefan Weil Looks like I missed an important discussion once again :) In the future don't hesitate to put me in copy for Windows and or IO loop subjects. On 02/21/2013 09:13 AM, Roy Tam wrote: > 2013/2/21 Roy Tam : >> 2013/2/21 Paolo Bonzini : >>> Il 21/02/2013 01:35, Roy Tam ha scritto: >>>>>> QEMU system emulation has been thread-safe for a long time, and >>>>>> setting the CPU affinity is hurting performance badly. Remove >>>>>> the bogus code. Actually it was not thread-safe on Windows because we don't have signals. On Linux, cpu_signal() is executed in the TCG thread context, on Windows, it's executed in IO thread context. This leads to memory synchronization issues. >>>>>> >>>>>> Jacob Kroon reports that the time to boot his VxWorks image goes from >>>>>> "3 minutes passed and I still haven't made it that far" to ~140s. >>>>>> >>>> Yes it does work better for fdostest.img, but when I tried to boot >>>> ttylinux-i686-14.0.iso, qemu freezes after showing "loading vmlinuz >>>> ..." >>>> >>> >>> Did it work without the patch? >> >> Yes, at least linux kernel starts but stalls when hitting IO-APIC >> thingy, with noapic boot switch it stalls after detecting ttyS0 >> >> With patch, QEMU is unresponsive when loading vmlinuz (not even >> showing "Decompressing Linux" message) > > Clarify that it boots fine sometimes, but when QEMU freezes, there is > a thread busy-waiting(seems so): > http://i.imgur.com/LUJjd8r.png > As I said in the patch set submitted yesterday, we've be through this kind of problem already. And it was not easy to debug (to say the least). The freezes that your are observing is due to a bad memory synchronization, between exit_request (global) and cpu->exit_request. This is fixed by the second patch of my set "Ensure good ordering of memory instruction in cpu_exec". -- Fabien Chouteau