From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQ1VR-0005WE-CY for qemu-devel@nongnu.org; Thu, 22 Jan 2009 10:30:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQ1VO-0005T5-F3 for qemu-devel@nongnu.org; Thu, 22 Jan 2009 10:30:07 -0500 Received: from [199.232.76.173] (port=42612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQ1VO-0005Sj-4E for qemu-devel@nongnu.org; Thu, 22 Jan 2009 10:30:06 -0500 Received: from yx-out-1718.google.com ([74.125.44.154]:53797) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQ1VM-0002Ij-PO for qemu-devel@nongnu.org; Thu, 22 Jan 2009 10:30:05 -0500 Received: by yx-out-1718.google.com with SMTP id 3so1764425yxi.82 for ; Thu, 22 Jan 2009 07:30:03 -0800 (PST) Message-ID: <497890ED.6000109@codemonkey.ws> Date: Thu, 22 Jan 2009 09:29:49 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [6391] Fix nographic mode and VNC References: <200901220004.11338.paul@codesourcery.com> <4977E87A.5040904@codemonkey.ws> <200901220423.23551.paul@codesourcery.com> In-Reply-To: <200901220423.23551.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Blue Swirl , qemu-devel@nongnu.org Paul Brook wrote: >> cpu_exec() spins in a loop checking for 'event_pending'. This is set >> whenever the host_alarm_timer callback signals. Alternatively, a halted >> guest will cause cpu_exec() to exit. Only then do you do a select() on >> pending IO. >> > > Ah, I see. > > >> If you are using dynticks as your clock, the guest has a slow clock, and >> the guest is not using halt instructions, then you will not poll IO >> until the next guest timer tick b/c your guest is just going to spin. >> >> There are three possible solutions. Set SIGIO on every file descriptor >> so that TCG breaks whenever IO is pending. Besides ugliness, this fails >> because not every type of file descriptor supports SIGIO. >> >> A second solution is to use a polling select() in cpu_exec. Since >> you're adding a system call (and a rather heavy one) in the fast path, >> this is going to likely hurt TCG performance. >> > > This won't work. If the guest really is in a tight loop then TB chaining means > it will never exit translated code. > But then signal delivery wouldn't either, right? That suggests that if the guest is in a tight loop right now, QEMU will freeze. There's a fair bit of code that is safe to run along side of TCG. If we separate the locking for the device model code from every thing (the monitor, vnc, sdl, etc.), then we could still let QEMU be responsive even in such a condition. >> The third possibility is to have the select() run in a separate thread >> from the TCG cpu_exec() loop. cpu_exec() would do an atomic read of >> 'event_pending' and the IO thread would do an atomic write of >> 'event_pending' whenever select() returned a writable file descriptor. >> > > This suffers from the same problem described above. You need to force the main > execution thread to break out of the translated loop. In practice this > probably means sending a signal to the main thread. How does a signal break translated loop execution other than by setting event_pending? The actual signal isn't going to make a difference, it's just setting event_pending=1 that causes it to break out of the loop IIUC. Regards, Anthony Liguori > You could check > event_pending at the start of every TB, but that's likely to incur a fairly > big performance hit. > > Paul >