aboutsummaryrefslogtreecommitdiff
path: root/ioport-user.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2011-04-13 10:03:43 +0200
committerEdgar E. Iglesias <edgar.iglesias@gmail.com>2011-04-15 09:27:56 +0200
commit3b2319a30b5ae528787bf3769b1a28a863b53252 (patch)
tree206e5221bc65ea69cf03e60f72a006bef55f0cae /ioport-user.c
parent420b6c317de87890e06225de6e2f8af7bf714df0 (diff)
really fix -icount in the iothread case
The correct fix for -icount is to consider the biggest difference between iothread and non-iothread modes. In the traditional model, CPUs run _before_ the iothread calls select (or WaitForMultipleObjects for Win32). In the iothread model, CPUs run while the iothread isn't holding the mutex, i.e. _during_ those same calls. So, the iothread should always block as long as possible to let the CPUs run smoothly---the timeout might as well be infinite---and either the OS or the CPU thread itself will let the iothread know when something happens. At this point, the iothread wakes up and interrupts the CPU. This is exactly the approach that this patch takes: when cpu_exec_all returns in -icount mode, and it is because a vm_clock deadline has been met, it wakes up the iothread to process the timers. This is really the "bulk" of fixing icount. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Diffstat (limited to 'ioport-user.c')
0 files changed, 0 insertions, 0 deletions