[Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD

[Jan Kiszka]

On 2011-02-15 21:04, Marcelo Tosatti wrote:
> On Tue, Feb 15, 2011 at 07:58:53PM +0100, Jan Kiszka wrote:
>> On 2011-02-15 18:54, Marcelo Tosatti wrote:
>>>
>>> Note: to be applied to uq/master.
>>>
>>> In icount mode, halt emulation should take into account the nearest event 
>>> when sleeping.
>>>
>>> Signed-off-by: Marcelo Tosatti <address@hidden>
>>> Reported-and-tested-by: "Edgar E. Iglesias" <address@hidden>
>>>
>>> diff --git a/cpus.c b/cpus.c
>>> index 468544c..21c3eba 100644
>>> --- a/cpus.c
>>> +++ b/cpus.c
>>> @@ -770,7 +770,7 @@ static void qemu_tcg_wait_io_event(void)
>>>      CPUState *env;
>>>  
>>>      while (all_cpu_threads_idle()) {
>>> -        qemu_cond_timedwait(tcg_halt_cond, &qemu_global_mutex, 1000);
>>> +        qemu_cond_timedwait(tcg_halt_cond, &qemu_global_mutex, 
>>> qemu_calculate_timeout());
>>
>> checkpatch.pl would complain here.
>>
>> More important: Paolo was proposing patches to eliminate all those fishy
>> cond_wait timeouts. That's probably the better way to go. The timeouts
>> only paper over missing signaling.
>>
>>>      }
>>>  
>>>      qemu_mutex_unlock(&qemu_global_mutex);
>>> diff --git a/vl.c b/vl.c
>>> index b436952..8ba7e9d 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -1335,7 +1335,7 @@ void main_loop_wait(int nonblocking)
>>>      if (nonblocking)
>>>          timeout = 0;
>>>      else {
>>> -        timeout = qemu_calculate_timeout();
>>> +        timeout = 1000;
>>>          qemu_bh_update_timeout(&timeout);
>>>      }
>>>  
>>
>> Isn't this path also relevant for !IOTHREAD? What's the impact of this
>> change for that configuration?
> 
> Timeout changes from 5s to 1s.
> 

... if (!vm_running).

This patch does have side effects on !IOTHREAD. I doubt the above hunk
can be correct.

What kind of timeout is qemu_calculate_timeout returning?

Jan

signature.asc
Description: OpenPGP digital signature