Patchwork qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX

login
register
mail settings
Submitter Stefano Stabellini
Date June 12, 2012, 1:32 p.m.
Message ID <alpine.DEB.2.02.1206121429350.14957@kaball.uk.xensource.com>
Download mbox | patch
Permalink /patch/164417/
State New
Headers show

Comments

Stefano Stabellini - June 12, 2012, 1:32 p.m.
On Tue, 12 Jun 2012, Andreas Färber wrote:
> Am 12.06.2012 14:37, schrieb Stefano Stabellini:
> > On Tue, 12 Jun 2012, Andreas Färber wrote:
> >> Am 12.06.2012 10:24, schrieb Andreas Färber:
> >>> Am 29.05.2012 15:35, schrieb Stefano Stabellini:
> >>> The check-qtest-i386 qemu-system-i386 process now hangs at ~98% CPU,
> > 
> > Does this mean that increasing the timeout caused a busy loop somewhere
> > in the test? But if we set the max timeout value to INT32_MAX doesn't
> > happen?
> 
> Note that this is solely about qtest, which I never saw working
> (probably didn't try before). Regular system emulation seemed to work
> just fine.
> 
> Where would I try INT32_MAX for comparison?

the following patch (to be applied on top of the other one) should do the trick:
Andreas Färber - June 28, 2012, 8:40 a.m.
Am 12.06.2012 15:32, schrieb Stefano Stabellini:
> On Tue, 12 Jun 2012, Andreas Färber wrote:
>> Am 12.06.2012 14:37, schrieb Stefano Stabellini:
>>> On Tue, 12 Jun 2012, Andreas Färber wrote:
>>>> Am 12.06.2012 10:24, schrieb Andreas Färber:
>>>>> Am 29.05.2012 15:35, schrieb Stefano Stabellini:
>>>>> The check-qtest-i386 qemu-system-i386 process now hangs at ~98% CPU,
>>>
>>> Does this mean that increasing the timeout caused a busy loop somewhere
>>> in the test? But if we set the max timeout value to INT32_MAX doesn't
>>> happen?
>>
>> Note that this is solely about qtest, which I never saw working
>> (probably didn't try before). Regular system emulation seemed to work
>> just fine.
>>
>> Where would I try INT32_MAX for comparison?
> 
> the following patch (to be applied on top of the other one) should do the trick:
> 
> diff --git a/qemu-timer.c b/qemu-timer.c
> index d37a978..4fd3e1c 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -85,7 +85,7 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, int64_t current_time)
>  
>  static int64_t qemu_next_alarm_deadline(void)
>  {
> -    int64_t delta = INT64_MAX;
> +    int64_t delta = INT32_MAX;
>      int64_t rtdelta;
>  
>      if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
> @@ -113,7 +113,7 @@ static int64_t qemu_next_alarm_deadline(void)
>  static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
>  {
>      int64_t nearest_delta_ns = qemu_next_alarm_deadline();
> -    if (nearest_delta_ns < INT64_MAX) {
> +    if (nearest_delta_ns < INT32_MAX) {
>          t->rearm(t, nearest_delta_ns);
>      }
>  }

Seems I forgot to reply that this INT32_MAX diff didn't make a change.

However, Anthony's "qtest: fix infinite loop when QEMU aborts abruptly"
patch that got committed combined with the original INT64_MAX patch here
makes qtest finally work on Darwin!

Thanks to everyone assisting,

Andreas

Patch

diff --git a/qemu-timer.c b/qemu-timer.c
index d37a978..4fd3e1c 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -85,7 +85,7 @@  static bool qemu_timer_expired_ns(QEMUTimer *timer_head, int64_t current_time)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta = INT64_MAX;
+    int64_t delta = INT32_MAX;
     int64_t rtdelta;
 
     if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
@@ -113,7 +113,7 @@  static int64_t qemu_next_alarm_deadline(void)
 static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
 {
     int64_t nearest_delta_ns = qemu_next_alarm_deadline();
-    if (nearest_delta_ns < INT64_MAX) {
+    if (nearest_delta_ns < INT32_MAX) {
         t->rearm(t, nearest_delta_ns);
     }
 }