qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos


From: Paolo Bonzini
Subject: Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
Date: Tue, 29 May 2012 14:21:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Il 29/05/2012 14:01, Stefano Stabellini ha scritto:
> On Mon, 28 May 2012, Paolo Bonzini wrote:
>> Il 28/05/2012 21:40, Andreas Färber ha scritto:
>>> I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with
>>> EINVAL during `make check` on both platforms. The value of
>>> nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it
>>> possible that this value is too large for it_value on some platforms?
>>> Apple's man page mentions that as possible reason for EINVAL but doesn't
>>> describe how to obtain such an upper value, nor of course where in the
>>> QEMU code base we would need to make adaptions. ;)
>>>
>>> Any suggestions?
>>
>> You shouldn't call the rearm function at all if you get INT64_MAX.  This
>> applies to all timers.
> 
> Yep. In fact qemu_rearm_alarm_timer returns immediately if none of the
> clocks have active timers.
> However if at least one of them does, we call qemu_next_alarm_deadline
> (that potentially can return INT64_MAX) and then rearm.
> 
> So for example if the clock that has active timers is disabled (I don't
> if it is possible to get in this state), qemu_next_alarm_deadline would
> return INT64_MAX.
> I think we should make the appended change in order to make the code
> more reliable.

Yes, that makes sense, can you submit it with SoB?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]