Patchwork [v2,39/39] raw-win32: implement native asynchronous I/O

login
register
mail settings
Submitter Paolo Bonzini
Date Nov. 22, 2012, 3:16 p.m.
Message ID <50AE41CC.7040705@redhat.com>
Download mbox | patch
Permalink /patch/201062/
State New
Headers show

Comments

Paolo Bonzini - Nov. 22, 2012, 3:16 p.m.
Il 22/11/2012 14:34, Jan Kiszka ha scritto:
> 
> =>0 0xf77c242e __kernel_vsyscall+0xe() in [vdso].so (0x0519df88)
>   1 0xf761f10b __libc_read+0x4a() in libpthread.so.0 (0x0519df88)
>   2 0x7bc78c98 in ntdll (+0x68c97) (0x0519df88)
>   3 0x7bc7b0a3 in ntdll (+0x6b0a2) (0x0519e1b8)
>   4 0x7bc7b195 NtWaitForMultipleObjects+0x54() in ntdll (0x0519e1e8)
>   5 0x7b86de9f WaitForMultipleObjectsEx+0xee() in kernel32 (0x0519e338)
>   6 0x7b86df1a WaitForMultipleObjects+0x39() in kernel32 (0x0519e368)
>   7 0x0040301b aio_poll+0x16a(ctx=0x157610, blocking=<is not available>) [/data/qemu/aio-win32.c:178] in qemu-system-arm (0x00000001)
>   8 0x004feec3 qemu_aio_wait+0x22() [/data/qemu/main-loop.c:442] in qemu-system-arm (0x0105bdec)
>   9 0x00417166 bdrv_rw_co+0xa5(bs=0x159648, sector_num=<internal error>, buf="¹¸ÿ¦
>                                                                                   ", nb_sectors=0x4, is_write=true) [/data/qemu/block.c:1997] in qemu-system-arm (0x0105bdec)
>   10 0x00495544 in qemu-system-arm (+0x95543) (0x0105bdec)
>   11 0x0049592a pflash_write+0x3b9(pfl=0xd6f16e0, offset=<internal error>, value=0x98f7fb1d, width=0x4, be=0) [/data/qemu/hw/pflash_cfi01.c:405] in qemu-system-arm (0x0105bdec)
>   12 0x00618a7e io_mem_write+0xed(mr=0xd6f2a48, addr=0x105bdec, val=0x98f7fb1d, size=0x4) [/data/qemu/memory.c:911] in qemu-system-arm (0x00000004)
>   13 0x0064088c helper_stl_mmu+0x2fb(env=0x15e268, addr=0xca05bdec, val=0x98f7fb1d, mmu_idx=0) [/data/qemu/softmmu_template.h:231] in qemu-system-arm (0x3700001e)
>   14 0x02136637 (0x0015e268)
> 
> It's the VCPU thread stuck in aio_poll, holding the BQL, blocking the
> iothread this way as well. Is there some race that prevents we receive
> the proper IO completion signal? Any states I should check?

Ah, so it wasn't fixed by the TLS change?

Instead of tracing, can you try adding printfs in aio_worker
(block/raw-win32.c), and also in thread_pool_active and
event_notifier_ready (thread-pool.c)?

This patch can help gathering debug output, it will place it into a
console window.


Paolo
Jan Kiszka - Nov. 22, 2012, 3:53 p.m.
On 2012-11-22 16:16, Paolo Bonzini wrote:
> Il 22/11/2012 14:34, Jan Kiszka ha scritto:
>>
>> =>0 0xf77c242e __kernel_vsyscall+0xe() in [vdso].so (0x0519df88)
>>   1 0xf761f10b __libc_read+0x4a() in libpthread.so.0 (0x0519df88)
>>   2 0x7bc78c98 in ntdll (+0x68c97) (0x0519df88)
>>   3 0x7bc7b0a3 in ntdll (+0x6b0a2) (0x0519e1b8)
>>   4 0x7bc7b195 NtWaitForMultipleObjects+0x54() in ntdll (0x0519e1e8)
>>   5 0x7b86de9f WaitForMultipleObjectsEx+0xee() in kernel32 (0x0519e338)
>>   6 0x7b86df1a WaitForMultipleObjects+0x39() in kernel32 (0x0519e368)
>>   7 0x0040301b aio_poll+0x16a(ctx=0x157610, blocking=<is not available>) [/data/qemu/aio-win32.c:178] in qemu-system-arm (0x00000001)
>>   8 0x004feec3 qemu_aio_wait+0x22() [/data/qemu/main-loop.c:442] in qemu-system-arm (0x0105bdec)
>>   9 0x00417166 bdrv_rw_co+0xa5(bs=0x159648, sector_num=<internal error>, buf="¹¸ÿ¦
>>                                                                                   ", nb_sectors=0x4, is_write=true) [/data/qemu/block.c:1997] in qemu-system-arm (0x0105bdec)
>>   10 0x00495544 in qemu-system-arm (+0x95543) (0x0105bdec)
>>   11 0x0049592a pflash_write+0x3b9(pfl=0xd6f16e0, offset=<internal error>, value=0x98f7fb1d, width=0x4, be=0) [/data/qemu/hw/pflash_cfi01.c:405] in qemu-system-arm (0x0105bdec)
>>   12 0x00618a7e io_mem_write+0xed(mr=0xd6f2a48, addr=0x105bdec, val=0x98f7fb1d, size=0x4) [/data/qemu/memory.c:911] in qemu-system-arm (0x00000004)
>>   13 0x0064088c helper_stl_mmu+0x2fb(env=0x15e268, addr=0xca05bdec, val=0x98f7fb1d, mmu_idx=0) [/data/qemu/softmmu_template.h:231] in qemu-system-arm (0x3700001e)
>>   14 0x02136637 (0x0015e268)
>>
>> It's the VCPU thread stuck in aio_poll, holding the BQL, blocking the
>> iothread this way as well. Is there some race that prevents we receive
>> the proper IO completion signal? Any states I should check?
> 
> Ah, so it wasn't fixed by the TLS change?

This version was built with my more recent opensuse mingw toolchain,
thus isn't affected by the TLS issue.

> 
> Instead of tracing, can you try adding printfs in aio_worker
> (block/raw-win32.c), and also in thread_pool_active and
> event_notifier_ready (thread-pool.c)?
> 
> This patch can help gathering debug output, it will place it into a
> console window.
> 
> diff --git a/vl.c b/vl.c
> index c8e9c78..5398178 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3531,6 +3531,10 @@ int main(int argc, char **argv, char **envp)
>      }
>      loc_set_none();
> 
> +    AllocConsole();
> +    freopen("CONIN$", "rb", stdin);
> +    freopen("CONOUT$", "wb", stdout);
> +    freopen("CONOUT$", "wb", stderr);
>      if (qemu_init_main_loop()) {
>          fprintf(stderr, "qemu_init_main_loop failed\n");
>          exit(1);

Ok, will dig into this.

Thanks,
Jan

Patch

diff --git a/vl.c b/vl.c
index c8e9c78..5398178 100644
--- a/vl.c
+++ b/vl.c
@@ -3531,6 +3531,10 @@  int main(int argc, char **argv, char **envp)
     }
     loc_set_none();

+    AllocConsole();
+    freopen("CONIN$", "rb", stdin);
+    freopen("CONOUT$", "wb", stdout);
+    freopen("CONOUT$", "wb", stderr);
     if (qemu_init_main_loop()) {
         fprintf(stderr, "qemu_init_main_loop failed\n");
         exit(1);