|
From: | Paolo Bonzini |
Subject: | [Qemu-devel] Re: [PATCH v2 0/3] really fix -icount with iothread |
Date: | Fri, 11 Mar 2011 14:36:49 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |