| Message ID | 1361367811-13288-2-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
2013/2/20 Paolo Bonzini <pbonzini@redhat.com>: > QEMU system emulation has been thread-safe for a long time, and > setting the CPU affinity is hurting performance badly. Remove > the bogus code. > > 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 ..." > Cc: qemu-stable@nongnu.org > Tested-by: Jacob Kroon <jacob.kroon@gmail.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > Jacob, this is "patch 3" you tested. > > os-win32.c | 18 ------------------- > 1 file changed, 18 deletions(-) > > diff --git a/os-win32.c b/os-win32.c > index 9673a81..3d43604 100644 > --- a/os-win32.c > +++ b/os-win32.c > @@ -69,25 +69,7 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type) > > void os_setup_early_signal_handling(void) > { > - /* Note: cpu_interrupt() is currently not SMP safe, so we force > - QEMU to run on a single CPU */ > - HANDLE h; > - DWORD_PTR mask, smask; > - int i; > - > SetConsoleCtrlHandler(qemu_ctrl_handler, TRUE); > - > - h = GetCurrentProcess(); > - if (GetProcessAffinityMask(h, &mask, &smask)) { > - for(i = 0; i < 32; i++) { > - if (mask & (1 << i)) > - break; > - } > - if (i != 32) { > - mask = 1 << i; > - SetProcessAffinityMask(h, mask); > - } > - } > } > > /* Look for support files in the same directory as the executable. */ > -- > 1.8.1.2 > > >
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. >> > >> > 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? Paolo
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. >>> > >>> > 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) > > Paolo
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. >>>> > >>>> > 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 > >> >> Paolo
Il 21/02/2013 09:13, Roy Tam ha scritto: >> > >> > 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 > Do you have an image I can try on Linux or Wine? Paolo
2013/2/21 Paolo Bonzini <pbonzini@redhat.com>: > Il 21/02/2013 09:13, Roy Tam ha scritto: >>> > >>> > 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 >> > > Do you have an image I can try on Linux or Wine? even fdostest.img can trigger this situation in WinXP. > > Paolo
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".
diff --git a/os-win32.c b/os-win32.c index 9673a81..3d43604 100644 --- a/os-win32.c +++ b/os-win32.c @@ -69,25 +69,7 @@ static BOOL WINAPI qemu_ctrl_handler(DWORD type) void os_setup_early_signal_handling(void) { - /* Note: cpu_interrupt() is currently not SMP safe, so we force - QEMU to run on a single CPU */ - HANDLE h; - DWORD_PTR mask, smask; - int i; - SetConsoleCtrlHandler(qemu_ctrl_handler, TRUE); - - h = GetCurrentProcess(); - if (GetProcessAffinityMask(h, &mask, &smask)) { - for(i = 0; i < 32; i++) { - if (mask & (1 << i)) - break; - } - if (i != 32) { - mask = 1 << i; - SetProcessAffinityMask(h, mask); - } - } } /* Look for support files in the same directory as the executable. */