| commit | 7a5e5838116a752d51c443dbb1cc61541c02b597 | |
| author | Paolo Bonzini <pbonzini@redhat.com> | |
| Wed, 10 Mar 2010 10:38:42 +0000 (10 11:38 +0100) | ||
| committer | Anthony Liguori <aliguori@us.ibm.com> | |
| Wed, 17 Mar 2010 16:14:53 +0000 (17 11:14 -0500) | ||
| tree | f4dda33a278cfa0af40f598b64c1361cf0448aee | treesnapshot (tar.gz zip) |
| parent | 1828be316f6637d43dd4c4f5f32925b17fb8107f | commitdiff |
do not use qemu_event_increment outside qemu_notify_event
qemu_notify_event in the non-iothread case is only stopping the current
CPU. However, if the CPU is idle and the main loop is in the select
call then a call to qemu_event_increment is needed too (as done in
host_alarm_handler). Since in general one doesn't know whether the CPU
is executing or not, it is a safe bet to always do qemu_event_increment.
Another way to see it: after this patch qemu_event_increment is the
"common part" of qemu_notify_event for both the CONFIG_IOTHREAD and
!CONFIG_IOTHREAD cases, which makes sense.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu_notify_event in the non-iothread case is only stopping the current
CPU. However, if the CPU is idle and the main loop is in the select
call then a call to qemu_event_increment is needed too (as done in
host_alarm_handler). Since in general one doesn't know whether the CPU
is executing or not, it is a safe bet to always do qemu_event_increment.
Another way to see it: after this patch qemu_event_increment is the
"common part" of qemu_notify_event for both the CONFIG_IOTHREAD and
!CONFIG_IOTHREAD cases, which makes sense.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
| vl.c | diffblobblamehistory |