search for: main_loop_wait

...in an extremely condition, like creating 12 VMX domains and 4 XENU domains at the same time, sometimes we still can meet this bug. Attached is a demo script to start many domains. So we just wonder changing the timout value could not resolve this issue completely. At the same time, we found when main_loop_wait is increased to 100 ms, windows guest''s keyboard and mouse response is significantly slower. Ping _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

(I posted this on xen-users last week, and nobody seemed to know what was up. It is time, I suppose then, to dust off the debugger; I was hoping one of you could point me in the correct direction to begin troubleshooting this.) I''m HVM booting our install-disks (systemimager) here, and I''m spotting some weird performance issues. Our install uses rsync and prints every

...9 +648,14 @@ int main_loop(void) xenstore_record_dm_state("running"); while (1) { - while (!(vm_running && suspend_requested)) + while (!((vm_running && suspend_requested) || shutdown_requested)) /* Wait up to 10 msec. */ main_loop_wait(10); + + if (shutdown_requested) { + ret = EXCP_INTERRUPT; + break; + } fprintf(logfile, "device model saving state\n"); @@ -676,7 +682,7 @@ int main_loop(void) xenstore_record_dm_state("running"); } - return 0;...

[CC to qemu-devel since I'm obviously doing something wrong here, I'm just not sure what.] I was getting ready to add multiple threads to ‘qemu-img convert’ (the longest part of v2v conversions) when I noticed that it had them already! (To be fair this was only added in February this year so no wonder we didn't notice.) To enable parallel convert we would need to use the ‘qemu-img

...st one main loop thread in qemu-img.c:convert_do_copy(): for (i = 0; i < s->num_coroutines; i++) { s->co[i] = qemu_coroutine_create(convert_co_do_copy, s); s->wait_sector_num[i] = -1; qemu_coroutine_enter(s->co[i]); } while (s->running_coroutines) { main_loop_wait(false); } > > I did some testing to see what effect this has. For this I used a > large guest image which is approximately a third full of random data > (the rest being sparsely allocated): > > Source format: raw > Source virtual size: 100 GB > Source used...

...nt(vlan, tap_receive, NULL, s); - qemu_set_fd_handler(s->fd, tap_send, NULL, s); + qemu_set_fd_handler2(s->fd, tap_read_poll, tap_send, NULL, s); snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd); return s; } @@ -7717,6 +7736,8 @@ void main_loop_wait(int timeout) slirp_select_poll(&rfds, &wfds, &xfds); } #endif + virtio_net_poll(); + qemu_aio_poll(); if (vm_running) { -- 1.5.3.3

...nt(vlan, tap_receive, NULL, s); - qemu_set_fd_handler(s->fd, tap_send, NULL, s); + qemu_set_fd_handler2(s->fd, tap_read_poll, tap_send, NULL, s); snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd); return s; } @@ -7717,6 +7736,8 @@ void main_loop_wait(int timeout) slirp_select_poll(&rfds, &wfds, &xfds); } #endif + virtio_net_poll(); + qemu_aio_poll(); if (vm_running) { -- 1.5.3.3

...eue_host_notifier_read (n=0x1b23790) > at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:1116 > #5 0x00000000005d3c9c in qemu_iohandler_poll (pollfds=0x1aae200, ret=1) > at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/iohandler.c:143 > #6 0x00000000005d4702 in main_loop_wait (nonblocking=0) at > /usr/src/debug/app-emulation/qemu-9999/qemu-9999/main-loop.c:484 > #7 0x000000000066c583 in main_loop () at > /usr/src/debug/app-emulation/qemu-9999/qemu-9999/vl.c:2014 > #8 0x00000000006730d1 in main (argc=17, argv=0x7fffa93167c8, > envp=0x7fffa9316858) at &gt...

...opy(): > > for (i = 0; i < s->num_coroutines; i++) { > s->co[i] = qemu_coroutine_create(convert_co_do_copy, s); > s->wait_sector_num[i] = -1; > qemu_coroutine_enter(s->co[i]); > } > > while (s->running_coroutines) { > main_loop_wait(false); > } > >> I did some testing to see what effect this has. For this I used a >> large guest image which is approximately a third full of random data >> (the rest being sparsely allocated): >> >> Source format: raw >> Source virtual siz...

...le_ioreq (opaque=0x7f94fb39d3f0) at /opt/new/tools/qemu-xen-dir/xen-all.c:868 #7 0x00007f94fa5e3262 in qemu_iohandler_poll (readfds=0x7f94faeea7a0 <rfds>, writefds=0x7f94faeea820 <wfds>, xfds=<optimized out>, ret=<optimized out>) at iohandler.c:125 #8 0x00007f94fa5ec51d in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:418 #9 0x00007f94fa6616dc in main_loop () at vl.c:1770 #10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:3999 It looks mapcache has something wrong because memcpy failed with the address from ma...

...06edf65 in virtio_queue_host_notifier_read (n=0x1b23790) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:1116 #5 0x00000000005d3c9c in qemu_iohandler_poll (pollfds=0x1aae200, ret=1) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/iohandler.c:143 #6 0x00000000005d4702 in main_loop_wait (nonblocking=0) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/main-loop.c:484 #7 0x000000000066c583 in main_loop () at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/vl.c:2014 #8 0x00000000006730d1 in main (argc=17, argv=0x7fffa93167c8, envp=0x7fffa9316858) at /usr/src/debug/app-emulation...

...06edf65 in virtio_queue_host_notifier_read (n=0x1b23790) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/hw/virtio/virtio.c:1116 #5 0x00000000005d3c9c in qemu_iohandler_poll (pollfds=0x1aae200, ret=1) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/iohandler.c:143 #6 0x00000000005d4702 in main_loop_wait (nonblocking=0) at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/main-loop.c:484 #7 0x000000000066c583 in main_loop () at /usr/src/debug/app-emulation/qemu-9999/qemu-9999/vl.c:2014 #8 0x00000000006730d1 in main (argc=17, argv=0x7fffa93167c8, envp=0x7fffa9316858) at /usr/src/debug/app-emulation...

When I submitted the qcow2 patch for blktap, suggestions came up that the qemu block drivers should be used also for blktap to eliminate the current code duplication in ioemu and blktap. The attached patch adds support for a tap:ioemu pseudo driver. Devices using this driver won''t use tapdisk (containing the code duplication) any more, but will connect to the qemu-dm of the domain. In

(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.