qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)
Date: Wed, 16 Feb 2011 10:32:25 +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 02/15/2011 09:56 PM, Marcelo Tosatti wrote:
Note: to be applied to uq/master.

In icount mode, halt emulation should take into account the nearest
event when sleeping.

I agree with Jan that this patch is not the best solution, if not incorrect.

However, in the iothread, the main loop can kick the VCPU thread instead of running cpu_exec_all like it does in non-iothread mode. Something like this:

diff --git a/vl.c b/vl.c
index b436952..7835317 100644
--- a/vl.c
+++ b/vl.c
@@ -1425,7 +1425,9 @@ static void main_loop(void)
     qemu_main_loop_start();

     for (;;) {
-#ifndef CONFIG_IOTHREAD
+#ifdef CONFIG_IOTHREAD
+        qemu_cpu_kick(first_cpu);
+#else
         nonblocking = cpu_exec_all();
         if (vm_request_pending()) {
             nonblocking = true;

I don't like this 100% because it relies on the fact that there is only one TCG execution thread. In a multithreaded world you would:

1) have each CPU register its own instruction counter;

2) have each CPU register its own QEMU_CLOCK_REALTIME timer based on qemu_icount_delta() and arm it just before going to sleep; the timer kicks the CPU.

3) remove all icount business from qemu_calculate_timeout.

Item (3) is what makes me prefer my patch above (if it works) to Marcelo's. Marcelo's patch is tying even more qemu_calculate_timeout to the icount. So if anything, a patch tweaking the timedwait like Marcelo's should use something based on qemu_icount_delta().

Paolo



reply via email to

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