From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHRZ7-0005Jk-IT for qemu-devel@nongnu.org; Tue, 21 Jul 2015 03:02:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHRZ3-0001uA-Jl for qemu-devel@nongnu.org; Tue, 21 Jul 2015 03:02:13 -0400 Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:36489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHRZ3-0001tj-DX for qemu-devel@nongnu.org; Tue, 21 Jul 2015 03:02:09 -0400 Received: by wgbcc4 with SMTP id cc4so54777220wgb.3 for ; Tue, 21 Jul 2015 00:02:08 -0700 (PDT) Sender: Richard Henderson References: <87h9ph7cid.fsf@fimbulvetr.bsc.es> From: Richard Henderson Message-ID: <55ADEE6C.303@twiddle.net> Date: Tue, 21 Jul 2015 08:02:04 +0100 MIME-Version: 1.0 In-Reply-To: <87h9ph7cid.fsf@fimbulvetr.bsc.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] How to break cpu_tb_exec()? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jun Koi , Peter Maydell , "qemu-devel@nongnu.org" On 07/06/2015 12:26 PM, Lluís Vilanova wrote: > Jun Koi writes: > >> On Sat, Jul 4, 2015 at 1:12 AM, Peter Maydell wrote: >> On 3 July 2015 at 18:10, Jun Koi wrote: >>> On Sat, Jul 4, 2015 at 1:06 AM, Peter Maydell >>> wrote: >>>> On 3 July 2015 at 18:02, Jun Koi wrote: >>>>> If this is true, then what if this TB is running infinitely, and do not >>>>> return, or it is in a very long loop? In this case, TCG thread cannot >> be >>>>> interrupted? >>>> >>>> Every TB starts with a little bit of generated code that checks >>>> the 'tcg_exit_req' flag in the CPUState for the CPU (see the >>>> gen_tb_start() function). If some other part of QEMU wants the >>>> CPU to stop running guest code and return to the top level loop, >>>> it calls cpu_exit() which sets this flag. >>> >>> >>> But this does not answer my question yet: if we the flag is only >>> enable when TB already enters the "long loop", then nothing can break >>> this TB execution? > >> We check the flag for every TB we execute. Therefore in any >> loop we must check the flag each time round the loop. So >> if another thread sets the flag, we will exit. > >> (A TB is always ended by any kind of branch instruction, >> so you can't have a loop within a single TB. A tight loop >> turns into a TB that ends with "branch back to the start >> of this TB", but that will re-execute the flag-check code.) > > >> Oh right, this tight loop is my main concern. It makes sense now. > > I'm not sure if "rep"-style x86 instructions loop inside the same TB, though. They do not. r~