Re: [Qemu-devel] [PATCH 1/2] win32: do not set CPU affinity

[Fabien Chouteau <chouteau@adacore.com>]

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 <roytam@gmail.com>:
>> 2013/2/21 Paolo Bonzini <pbonzini@redhat.com>:
>>> 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