From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zen.linaro.local ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id b8sm39776263wrb.17.2017.02.02.05.25.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 05:25:28 -0800 (PST) Received: from zen (localhost [127.0.0.1]) by zen.linaro.local (Postfix) with ESMTPS id 482323E0126; Thu, 2 Feb 2017 13:25:32 +0000 (GMT) References: <87bmuk4zyb.fsf@linaro.org> <87a8a44wi9.fsf@linaro.org> User-agent: mu4e 0.9.19; emacs 25.1.91.6 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Peter Maydell Cc: MTTCG Devel , QEMU Developers , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= , Alvise Rigo , "Emilio G. Cota" , Pranith Kumar , Nikunj A Dadhania , Mark Burton , Paolo Bonzini , Jan Kiszka , Fedorov Sergey , Richard Henderson , Claudio Fontana , Bamvor Zhang Jian , "open list\:ARM" Subject: Re: [PATCH v8 23/25] target-arm: introduce ARM_CP_EXIT_PC In-reply-to: Date: Thu, 02 Feb 2017 13:25:32 +0000 Message-ID: <878tpo4tdf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TUID: kxrUx9oZKVLM Peter Maydell writes: > On 2 February 2017 at 12:17, Alex Bennée wrote: >> Peter Maydell writes: >>> Your longjump is effectively skipping the normal "end of the TB" code, >>> which is what usually does the set_condexec for you. At the end of a >>> TB the expectation is that everything's been sync'd back to the CPU >>> state structure. >> >> Hmm so as long as the tlb flush helpers don't set ARM_CP_SUPPRESS_TB_END >> things should just work normally? > > If they're register writes, yes -- we end the TB on writes but not > on reads (on the assumption that only writes might modify state that > requires a TB end). If the TLB instructions are reads then we can > add a "force TB end" flag. > >> Is shouldn't matter if the TB with the >> flush is chained to a new TB as the exit_request test should fire before >> any more state changing operations happen? > > I think so, but again if you know that you're always going to exit > the TB then there's no point setting it up so it might chain. So setting s->is_jmp = DISAS_JUMP ensures that? -- Alex Bennée From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZHOI-0006Hw-3l for qemu-devel@nongnu.org; Thu, 02 Feb 2017 08:25:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZHOF-0001il-1w for qemu-devel@nongnu.org; Thu, 02 Feb 2017 08:25:34 -0500 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:33720) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZHOE-0001iI-Rd for qemu-devel@nongnu.org; Thu, 02 Feb 2017 08:25:30 -0500 Received: by mail-wm0-x230.google.com with SMTP id t18so5279152wmt.0 for ; Thu, 02 Feb 2017 05:25:30 -0800 (PST) References: <87bmuk4zyb.fsf@linaro.org> <87a8a44wi9.fsf@linaro.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Thu, 02 Feb 2017 13:25:32 +0000 Message-ID: <878tpo4tdf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v8 23/25] target-arm: introduce ARM_CP_EXIT_PC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: MTTCG Devel , QEMU Developers , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= , Alvise Rigo , "Emilio G. Cota" , Pranith Kumar , Nikunj A Dadhania , Mark Burton , Paolo Bonzini , Jan Kiszka , Fedorov Sergey , Richard Henderson , Claudio Fontana , Bamvor Zhang Jian , "open list:ARM" Peter Maydell writes: > On 2 February 2017 at 12:17, Alex Bennée wrote: >> Peter Maydell writes: >>> Your longjump is effectively skipping the normal "end of the TB" code, >>> which is what usually does the set_condexec for you. At the end of a >>> TB the expectation is that everything's been sync'd back to the CPU >>> state structure. >> >> Hmm so as long as the tlb flush helpers don't set ARM_CP_SUPPRESS_TB_END >> things should just work normally? > > If they're register writes, yes -- we end the TB on writes but not > on reads (on the assumption that only writes might modify state that > requires a TB end). If the TLB instructions are reads then we can > add a "force TB end" flag. > >> Is shouldn't matter if the TB with the >> flush is chained to a new TB as the exit_request test should fire before >> any more state changing operations happen? > > I think so, but again if you know that you're always going to exit > the TB then there's no point setting it up so it might chain. So setting s->is_jmp = DISAS_JUMP ensures that? -- Alex Bennée