On 05/30/2012 05:07 AM, Paolo Bonzini wrote:
Il 29/05/2012 19:09, Stefan Weil ha scritto:
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellini<stefano.stabell...@eu.citrix.com>
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
- int64_t nearest_delta_ns;
- if (!rt_clock->active_timers&&
- !vm_clock->active_timers&&
- !host_clock->active_timers) {
- return;
+ int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+ if (nearest_delta_ns< INT64_MAX) {
+ t->rearm(t, nearest_delta_ns);
}
- nearest_delta_ns = qemu_next_alarm_deadline();
- t->rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Reviewed-by: Stefan Weil<s...@weilnetz.de>
This patch clearly improves the current code and fixes
an abort on Darwin (reported by Andreas Färber) and maybe
other hosts. Therefore I changed the subject and suggest
to consider this patch for QEMU 1.1.
Not for 1.1.0. I'm just a few hours away from pushing the 1.1.0-rc4 tag and I
don't plan on doing any updates before GA unless something critical emerges.
Regards,
Anthony Liguori
Only with a Tested-by from Andreas.
Paolo
