[Qemu-devel] Re: [PATCH v2 0/3] really fix -icount with iothread

[Paolo Bonzini <pbonzini@redhat.com>]

On 03/11/2011 01:57 PM, Edgar E. Iglesias wrote:
> Hi Paulo,
>
> I gave this patchset a run and it runs icount and iothread very
> fast in all my testcases.

Thanks, that's good news.

> But, it suffers from the problem that commit
> 225d02cd1a34d5d87e8acefbf8e244a5d12f5f8c
> tried to fix.
>
> If the virtual CPU goes to sleep waiting for a future timer
> interrupt to wake it up, qemu deadlocks.
>
> The timer interrupt never comes because time is driven by
> icount, but the vCPU doesn't run any insns.

I'm not sure what it should wait for, though.  Is vm_clock supposed to 
be "a count of instructions, or real time if there is need for?"  So, 
it's not clear to me what the correct behavior should be in this case. 
Does it make sense to wait at all?

Thinking more about it, perhaps VCPUs should never go to sleep in icount 
mode if there is a pending vm_clock timer; rather time should just warp 
to the next vm_clock event with no sleep ever taking place.  (That's my 
reasoning for manual -icount mode, at least; I think "-icount auto" will 
just work thanks to the icount_rt_handler).

Bonus question: how does -icount mode makes sense at all for SMP? :)

Paolo