| commit | cf36b31db209a261ee3bc2737e788e1ced0a1bec | |
| author | Peter Chubb <peter.chubb@nicta.com.au> | |
| Fri, 20 Apr 2012 05:32:30 +0000 (20 15:32 +1000) | ||
| committer | Anthony Liguori <aliguori@us.ibm.com> | |
| Tue, 24 Apr 2012 14:50:31 +0000 (24 09:50 -0500) | ||
| tree | 331593a1b14358cba1b72dd622971274e58c77d5 | treesnapshot (tar.gz zip) |
| parent | dfe47e7029e117f65a14c0948021654f7f7d5d05 | commitdiff |
Limit ptimer rate to something achievable
If a guest sets very short timeouts, and asks for a timer to be reloaded on
timeout, QEMU can go to 100%CPU utilisation and become unresponsive,
as it is spending all its time generating timeout interrupts. On real
hardware this doesn't matter, as the interrupts are just coalesced,
and the effect is to have the interrupt asserted all the time.
This patch is a band-aid, that prevents timeouts less than 10
microseconds from being set. 10 microseconds is a limit that was
determined empirically on a variety of machines as the shortest that
allowed QEMU to pick up a control-a c sequence to get at the monitor.
Reported-by: Anna Lyons <anna.lyons@nicta.com.au>
Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If a guest sets very short timeouts, and asks for a timer to be reloaded on
timeout, QEMU can go to 100%CPU utilisation and become unresponsive,
as it is spending all its time generating timeout interrupts. On real
hardware this doesn't matter, as the interrupts are just coalesced,
and the effect is to have the interrupt asserted all the time.
This patch is a band-aid, that prevents timeouts less than 10
microseconds from being set. 10 microseconds is a limit that was
determined empirically on a variety of machines as the shortest that
allowed QEMU to pick up a control-a c sequence to get at the monitor.
Reported-by: Anna Lyons <anna.lyons@nicta.com.au>
Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
| hw/ptimer.c | diffblobblamehistory |