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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Fri, Mar 11, 2011 at 02:36:49PM +0100, Paolo Bonzini wrote:
> 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?

That was my initial local workaround. I just disabled the sleep mode
in the CPU and let it spin. The drawback is ofcourse that the tcg cpu
will consume 100% cpu time when using icount. I think that would be
a significant regression between non-iothread and iothread builds.


> 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 

Yes, something like that. Or somehow sleep for some time related to the
time left until the next event to avoid the warps from beeing too visible
externally (e.g like sending a network packet continously instead of
every 100ms). The important part is to make sure the insn counter makes
progress also when the vCPU is sleeping.


> 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? :)

Sorry, I don't know. I only use it with up. Maybe Paul has more info on
that.

Cheers